 Things are looking really great for this transition. :)
 All the builds now succeed, just doing rebuilds without ~.
 I'll give enabling it on my local machine a try...
[02:13] <valorie> did you get through to your other machine, tsimonq2?
[02:13] <tsimonq2> Not quite yet, but I can make it work without it.
[02:18]  * valorie sends snowshoes
[02:18] <tsimonq2> I need BOOTS! :)
[02:18] <tsimonq2> Snow is knee high
[02:18] <tsimonq2> School already cancelled for tomorrow
[02:19] <tsimonq2> valorie: I am *so* looking forward to get away from this snow. ;)
[02:19]  * valorie sends 7 league boots
[02:19] <valorie> and a horse and sleigh
[02:20] <tsimonq2> hah
[02:20] <tsimonq2> I need it, lol
 Upgraded and rebooted (for good measure), everything works \o/
 @mitya57 Feel free to take another look, but otherwise I can land it in ~ 8 hours after I sleep.
 That is, if QtWebEngine is done... :P
 The city falls asleep, the mafia wakes up.
 Qtwebengine is still building, when it is done I can publush it myself.
[08:32] <lubot3> mattia was removed by: mattia
[08:32] <mapreri> o.O I removed myself!
[08:33] <mitya57> Do you want to be added back?
[08:33] <mapreri> nope
[08:33] <mapreri> just commenting on the relayed message :)
[08:33] <mitya57> Ok :)
[08:33] <mapreri> I am not really contributing here, and it's bothering me having a telegram group that I don't even read :)
 @mitya57, >:D
 @mitya57, Ok. Just needs regenerated diffs and a publish button pressed.
 Already discussing with sil2100 et. al in #ubuntu-release
 (Document) http://vps.tsimonq2.net//file_3940.mp4
 If you need someone to push the button, ping me :)
 all pressed I think?
 Yep, published. \o/
[15:25] <lubot3> * tsimonq2 high fives @mitya57
 Ok, I did not even notice that :)
[15:25] <lubot3> * mitya57 high fives back
 That was really fast transition preparation, thanks! :)
[15:26] -queuebot:#ubuntu-qt- Unapproved: fcitx-qt5 (bionic-proposed/universe) [1.1.1-1build2 => 1.1.1-1build3] (input-methods, kubuntu, ubuntu-qt-packages) (sync)
[15:26] -queuebot:#ubuntu-qt- Unapproved: qt3d-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu2 => 5.9.5+dfsg-0ubuntu2] (qt5) (sync)
[15:26] -queuebot:#ubuntu-qt- Unapproved: pyqt5 (bionic-proposed/universe) [5.9.2+dfsg-1build2 => 5.10.1+dfsg-1ubuntu1] (kubuntu, qt5) (sync)
[15:26] -queuebot:#ubuntu-qt- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.4+dfsg-0ubuntu4 => 5.9.5+dfsg-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
[15:26] -queuebot:#ubuntu-qt- Unapproved: qtconnectivity-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (qt5) (sync)
[15:26] -queuebot:#ubuntu-qt- Unapproved: qtcreator (bionic-proposed/universe) [4.5.2-3ubuntu1 => 4.5.2-3ubuntu2] (qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtdoc-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtimageformats-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtdeclarative-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtlocation-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu2] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtpim-opensource-src (bionic-proposed/universe) [5.0~git20140515~29475884-0ubuntu24~6 => 5.0~git20140515~29475884-0ubuntu24~7] (qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtmultimedia-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtgraphicaleffects-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtquickcontrols-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtstyleplugins-src (bionic-proposed/universe) [5.0.0+git23.g335dbec-2build4 => 5.0.0+git23.g335dbec-2build5] (qt5, ubuntu-budgie, ubuntu-mate) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtsvg-opensource-src (bionic-proposed/main) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qttools-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qttranslations-opensource-src (bionic-proposed/main) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5, ubuntu-desktop) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtsensors-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:27] -queuebot:#ubuntu-qt- Unapproved: qtscript-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu1 => 5.9.5+dfsg-0ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtwayland-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu2 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtwebkit-opensource-src (bionic-proposed/universe) [5.212.0~alpha2-7build2 => 5.212.0~alpha2-7ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtserialport-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtwebsockets-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtx11extras-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu1 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:28] -queuebot:#ubuntu-qt- Unapproved: qtxmlpatterns-opensource-src (bionic-proposed/universe) [5.9.4-0ubuntu2+2 => 5.9.5-0ubuntu1] (kubuntu, qt5) (sync)
[15:33] -queuebot:#ubuntu-qt- Unapproved: accepted fcitx-qt5 [sync] (bionic-proposed) [1.1.1-1build3]
[15:34] -queuebot:#ubuntu-qt- Unapproved: accepted pyqt5 [sync] (bionic-proposed) [5.10.1+dfsg-1ubuntu1]
[15:37] <LocutusOfBorg> sigh
[15:37] <tsimonq2> :))
[15:43] <tsimonq2> Added to the transition tracker: https://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/594
[15:43] <tsimonq2> Everything should be accepted now.
[15:45] <tsimonq2> Ah, right. I did leave out one no-change rebuild...
[15:46] <tsimonq2> Can a Core Developer (maybe @mitya57 or LocutusOfBorg etc.) please no-change rebuild qtubuntu against qtbase-abi-5-9-5?
[15:52] <LocutusOfBorg> tsimonq2, when
[15:52] <tsimonq2> LocutusOfBorg: Hm?
[15:53] <LocutusOfBorg> is it published?
[15:53] <tsimonq2> Yes.
[15:54] <LocutusOfBorg> done.
[15:54] <tsimonq2> Thank you!
[15:54] <LocutusOfBorg> uw! it might be go un unapproed
[17:21] -queuebot:#ubuntu-qt- Unapproved: deepin-qt5dxcb-plugin (bionic-proposed/universe) [<IP_ADDRESS>+ds-1 => <IP_ADDRESS>+ds-1build1] (no packageset)
[17:21] -queuebot:#ubuntu-qt- Unapproved: accepted deepin-qt5dxcb-plugin [source] (bionic-proposed) [<IP_ADDRESS>+ds-1build1]
[17:22] -queuebot:#ubuntu-qt- Unapproved: dde-qt5integration (bionic-proposed/universe) [<IP_ADDRESS>+git20180208-1 => <IP_ADDRESS>+git20180208-1build1] (no packageset)
[17:22] -queuebot:#ubuntu-qt- Unapproved: accepted dde-qt5integration [source] (bionic-proposed) [<IP_ADDRESS>+git20180208-1build1]
[21:39] <mitya57> qtubuntu -0ubuntu6 is built against Qt 5.9.4 (see the build logs)
[21:39]  * mitya57 will upload -0ubuntu7 now
[21:43] <mitya57> Argh, there was already -0ubuntu7 in unapproved, my upload replaced it(?)


[01:40] <compdoc> when I scan comcast qam channels, the channel numbers show up as 2_1, etc rather than 2.1 so schdules direct cant seem to match stuff up. is there a website with info to help fix this?
[10:55] <ceelight> Hi everyone! Does anyone know, if mythbuntu can be installed over network (pxe)? Or does anyone know where I can find a mythbuntu pxe-image? Thanks!
[13:46] <ceelight> OK, trying it again: Hi everyone! Does anyone know, if mythbuntu can be installed over network (pxe)? Or does anyone know where I can find a mythbuntu pxe-image? Thanks!
[14:39] <mycoDA> ceelight - you can install mythbuntu over ubuntu
[14:39] <mycoDA> so yes
[14:39] <mycoDA> the package to add is mythbuntu-control-center
[14:39] <mycoDA> or mythbuntu-desktop
[17:24] <twooten> I have normal cable, no cable box, just coax coming in. will mythtv be able to change channels without any special equipment?
[17:41] <peter____> Anyone heard of these or anything similar working in Mythbuntu? http://www.amazon.co.uk/Handheld-Wireless-Windows-Keyboard-Control/dp/B003ZV3O86/ref=pd_sxp_f_pt
[18:51] <qwebirc40011> So does anyone know how to find out what version of LIRC i am running?
[18:56] <mrand> qwebirc40011: Well, before lirc was integrated into the kernel, you could find lirc in the synaptic list, or issue the command "apt-cache policy lirc"   On 10.10 or later, I'm not sure how.
[19:17] <qwebirc40011> Ok followed all the directions here - http://regx.dgswa.com/html/node/134, but it seems my brand new irblaster from irblaster .info isn't transmitting anyway to isolate if the IR transmitter is working?
[19:17] <Zinn> [regx.dgswa.com] How to get Comcast PACE DTA working in Myth in Ubuntu Hardy | regx.dgswa.com
[19:23] <dewman> hey there...
[19:23] <qwebirc40011> Allright I'm not sure I'm going to be able to get this serial IR transmitter working.  This http://www.usbuirt.com/ seems to be natively supported in mythbuntu, anyone have any experience with it?
[19:24] <qwebirc40011> Hey Deman
[19:26] <dewman> I noticed that oss support was removed in 10.10 Now I am having a heck of a time getting audio pctv hdtv 800i. I can audio out of my hdhomerun without any issues, but the anlog side of the 800i is being plain stubborn.
[19:26] <dewman> hey qwebirc40011
[19:27] <dewman> jeez my typing skills are lacking today.
[19:37] <dewman> the audio device for the 800i shows up as alsa:default. I can see the card get loaded in the kernel log, I check arecord -l and it shows up....Not sure what else I need to check.... I miss being able to use /dev/dsp1


[00:17] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu MATE: Ubuntu MATE 22.04 Release Notes @ https://ubuntu-mate.org/blog/ubuntu-mate-jammy-jellyfish-release-notes/
[10:41] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: The State of IoT – March 2022 @ https://ubuntu.com//blog/the-state-of-iot-march-2022
[11:02] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: The State of IoT – March 2022 @ https://ubuntu.com//blog/state-of-iot-march-2022
[15:52] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: ‘App Icons Taskbar’ Puts Running Apps in GNOME Shell’s Top Bar @ https://www.omgubuntu.co.uk/2022/03/app-icons-taskbar-gnome-extension (by Joey Sneddon)
[16:55] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu 22.04’s Snap-Only Software Store is a Bug, Not a Feature @ https://www.omgubuntu.co.uk/2022/03/ubuntu-22-04s-snap-only-software-store-is-a-bug-not-a-feature (by Joey Sneddon)
[20:00] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: The Keys to Successful Bug Reporting @ https://ubuntu.com//blog/the-keys-to-successful-bug-reporting
[22:14] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Getting started with Juju and Charmed Operators: three awesome videos @ https://ubuntu.com//blog/juju-and-charmed-operators-videos


[00:23] <xibalba> know of a way to firewall a shell user on aa system? say i give you a shell on my box / <IP_ADDRESS>. i dont want you accessing my home network at <IP_ADDRESS>/24 but i , from my reza account, want ot be able to hit my home network
[00:24] <Patrickdk> I can't remember if that is still supported with iptables or not
[00:24] <xibalba> i wonder if the ol' tcpwrappers could do it
[00:25] <Patrickdk> only if every program they used was build with tcpwrappers support
[00:25] <sarnold> xibalba: no, tcpwrappers is a voluntary deal, it wouldn't be a very good firewall
[00:25] <xibalba> ok
[00:25] <sarnold> xibalba: iptables --uid-owner is probably what you;re looking for, I've never tried it though.
[00:25] <xibalba> thanks i'll take a gander
[09:15] <makara> i want to keep revisions of conf files
[09:15] <makara> i've read of RCS
[09:15] <makara> apparently the syntax is cumbersome
[09:15] <makara> just looking for something simple and local
[09:28] <jamespage> zul, urgh - the webob update that just trickled through busted nova
[09:52] <makara> how can I measure the bandwidth savings that my squid proxy cache has provided?
[09:54] <makara> and is it possible for to get squid hooked up to avahi (like squid-deb-proxy) so I don't have to reconfigure my browser settings every time I come to the office?
[09:57] <makara> (i can't configure it as a transparent proxy)
[09:57] <yolanda> jamespage, i'm looking at the heat failure, missing a build-dep
[09:58] <jamespage> yolanda, yep - wanna propose a branch for that?
[09:58] <yolanda> sure
[10:01] <jamespage> yolanda, it might not build after that - webob just bumped version which is causing test failures as requirements < 1.3 in most projects
[10:01] <jamespage> but please do try :-)
[10:01] <yolanda> ok, trying now
[10:04] <yolanda> jamespage, it built!
[10:05] <jamespage> yolanda, if you wanted a bit of SRU practice: bug 1250654 looks like a good bit sized one
[10:07] <yolanda> ok
[10:08] <yolanda> jamespage https://code.launchpad.net/~yolanda.robla/heat/icehouse_add_lockfile/+merge/198699
[10:08] <jamespage> yolanda, niggle but please leave the changelog entry as UNRELEASED  - and add your entries using dch -t
[10:09] <yolanda> jamespage, i added entry with dch -t, is there something wrong?
[10:09] <jamespage> yolanda, did you do a dch -r as well?
[10:09] <yolanda> no
[10:10] <jamespage> how did it change from UNRELEASED to trusty ?
[10:10] <yolanda> i manually edited that
[10:11] <yolanda> jamespage, updated MP
[10:12] <jamespage> yolanda, so we should not be updating from UNRELEASED until someone actually does an upload to the archive
[10:13] <jamespage> then they do dch -r which updates the target and the timestamp on the changelog and do the upload
[10:13] <yolanda> good to know
[10:13] <yolanda> i normally tend to set the latest distribution name
[10:43] <yolanda> jamespage, i have a question about SRU process explained here. https://wiki.ubuntu.com/StableReleaseUpdates
[10:44] <yolanda> it says i need to fill an [Impact] , [TestCase] and [Regression Potential] comments. Where do i have to do it, in the same bug?
[11:17] <jamespage> yolanda, yes - in the description
[11:18] <yolanda> jamespage, and then i grab the bugfix from trusty and i update the package for saucy?
[11:18] <jamespage> yolanda, no
[11:18] <jamespage> you will need to cherry-pick the fix from upstream github and make it work for the version on saucy.
[11:18] <jamespage> yolanda, the bugfix in trusty is a new upstream release - you can't sru that
[11:19] <yolanda> jamespage, i meant that, sorry
[11:19] <yolanda> just look at that commit
[11:27] <jamespage> yolanda, the bug reporter is quite friendly - maybe you could ask him for a more specific test case configuration
[11:27] <jamespage> I suspect he'd also verify a fix for you as well once its in the proposed pockets
[11:28] <yolanda> jamespage, and SRU comments should be filed in same bug description, or create some other bug? i saw that in Launchpad there are specific SRU bugs
[11:29] <jamespage> yolanda, same bug - why would you raise another one?
[11:29] <jamespage> the SRU fixes that bug after all
[11:29] <yolanda> jamespage, just asking because I saw other independent bugs in Launchpad, I want to be sure that i'm doing the right thing :)
[11:30] <jamespage> yolanda, if we have minor release exceptions, then yes we would probably raise a specific SRU bug
[11:44] <rbasak> smoser: are we treating bug 1250390 as resolved? I know I haven't verified it, but it should be fixed now, right?
[11:44] <rbasak> jamespage: ^^
[11:44] <jamespage> rbasak, ta
[12:31] <zul> jamespage:  of course it did
[12:31] <jamespage> zul, \o/
[12:32] <swaT30> hey guys, sorry if you had already answered this, but any ETA on 2013.1.4 to be pushed into updates? I see that it has been in proposed for a while
[12:32] <zul> jamespage:  ill look when i get in
[12:40] <swaT30> @jamespage any idea?
[12:41] <jamespage> swaT30, sorry - about what (guess I must have missed something)
[12:41] <swaT30> any ETA on 2013.1.4 hitting updates in the UCA?
[12:41] <swaT30> :)
[12:49] <jamespage> swaT30, hmm - yes that has been sat in proposed for a while
[12:50] <jamespage> lemme kickoff the automated testing - if its all ok I'll promote today
[12:50] <swaT30> would be great to have it :)
[12:50] <swaT30> thanks !
[12:51] <swaT30> jamespage: I'll keep an eye on http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/grizzly_versions.html
[12:51] <swaT30> I assume that's as good a spot as any?
[13:11] <makara> i've logged in as user JIM and I need to run a command as GAX
[13:11] <makara> what 2 do?
[13:12] <makara> i don't know GAX's password
[13:12] <jamespage> swaT30, yes - thats good
[13:12] <jamespage> swaT30, there is also a notifications ML
[13:30] <smoser> rbasak, its not fix-released for sure.
[13:31] <smoser> as in no 'released' images.
[13:37] <makara> any idea how to execute a script on system start as given user?'
[13:40] <rbasak> makara: there are various ways. You could add something to /etc/rc.local that uses su or sudo. Or add an upstart job to /etc/init/ that uses setuid/setgid. Or even an @reboot job to cron.
[13:44] <makara> rbasak, and if I put "su - teamcity runAll.sh" in /etc/rc.local then why wouldn't get hung up on asking me for a password?
[13:44] <makara> like it would in a shell
[13:45] <rbasak> makara: rc.local runs as root, which should be able to su to any user without a password. Check it works by using "sudo -i" to get a root shell, and then test the su command you propose there.
[13:48] <jamespage> swaT30, tested OK - should be out on the archive in the next 2 hrs
[14:04] <paws> hello, can anyone tell me whats a good Cloud storage software, that i can host on my own server ?
[14:05] <zul> jamespage:  whats patch-branches in nova icehouse packaging?
[14:06] <jamespage> zul, uh?
[14:06] <zul> jamespage:  yeah...
[14:06] <zul> jamespage:  anyways its gone
[14:06] <jamespage> zul, I don't see that
[14:07] <zul> jamespage:  its an empty file in the debian directory
[14:07] <jamespage> not a clue
[14:07] <Felipe_C> Hi all, Has anyone heard of or actually tried those Paralella Boards to create a proof of concept mini cloud cluster?
[14:08] <jamespage> zul, its been there along time
[14:08] <zul> jamespage:  yeah well if anything breaks then ill blame myself
[14:10] <zul> jamespage:  https://code.launchpad.net/~zulcss/nova/webob/+merge/198751
[14:13] <zul> jamespage:  https://review.openstack.org/#/c/61742/ as well
[14:22] <zul> yolanda:  i just merged your heat fixed
[14:22] <yolanda> thx
[14:24] <swaT30> jamespage: thanks! on the ML, got the notifications
[14:30] <zul> jamespage:  trove is in openstack-ci now
[14:41] <zul> jamespage:  https://code.launchpad.net/~zulcss/cinder/webob/+merge/198752
[14:54] <bittin> Hired an ubuntu server from azure :)
[14:56] <jamespage> zul, how do you always manage to remove dep headers from patches?
[14:56] <zul> jamespage:  i dunno its an art i think :)
[14:56] <jamespage> zul, I'm putting in a conditional wait in nova-compute upstart that if libvirt-bin is installed, it will wait for it to reach running before starting
[14:57] <jamespage> should close out a couple of race bugs I've seen
[14:57] <jamespage> I *think* we need todo the same with neutron-ovs-cleanup
[14:57] <zul> jamespage:  sounds good
[15:09] <zul> jamespage:  yay trove needs a unpackaged dep
[15:16] <jamespage> zul, feedback on your MP
[15:16] <jamespage> sorry - git review
[15:17] <makara> exit
[15:17] <zul> jamespage:  i saw ill fix it up
[15:17] <jamespage> zul, I don't think we should unbound it - but < 1.4 is OK imho
[15:18] <zul> jamespage:  agreed
[15:23] <jamespage> zul, adam_g: https://code.launchpad.net/~james-page/nova/compute-plus-others/+merge/198763
[15:27] <zul> jamespage:  couple of things, while you are at it
[15:27] <jamespage> zul, sure
[15:27] <zul> jamespage:  i think the openssh-client can go away in the build-depends-indep
[15:28] <zul> jamespage:  curl can go away as well
[15:28] <jamespage> zul, what was that for?
[15:28] <zul> jamespage:  im not sure i think it was a diablo thing
[15:28] <zul> jamespage:  nova-uml should go away
[15:29] <jamespage> zul, actually openssh-client - still a runtime I think
[15:29] <jamespage> migrations
[15:29] <zul> jamespage:  ah yes
[15:29] <jamespage> live migrations and cold migrations
[15:29] <zul> ssh key-gen as well i guess
[15:30] <zul> jamespage:  but yeah git rid of uml as well :)
[15:30] <jamespage> zul, we don't like uml do we?
[15:31] <zul> jamespage:  makes the package less complicated ;)
[15:49] <yolanda> jamespage, i added a fix to rabbitmq charm https://code.launchpad.net/~yolanda.robla/charms/precise/rabbitmq-server/ha/+merge/198768
[15:49] <d1n0> I am having problems with maas. I have imported the boot images, but when I try and pxe boot a node.. it doesn't see the pxe template
[15:52] <zul> jamespage:  https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769
[15:55] <yolanda> jamespage, currently rabbitmq is relying on HA to create clusters. That is different on active-active. Should we set a config var in rabbit to specify if we want active-active or active-passive?
[15:56] <jamespage> yolanda, can we not determine which mode using relations?
[15:56] <jamespage> its only HA if it gets related to hacluster
[15:57] <jamespage> zul, can't drop openssh-client
[15:57] <zul> jamespage:  ok cool
[15:58] <yolanda> jamespage, i see, and act differently and set different vars depending on it. For example in active-active i need to send all the rabbitmq hosts
[15:59] <jamespage> yolanda, yes - that's right
[15:59] <yolanda> i could set a var in rabbitmq to tell glance for example, if rabbit uses active-active or active-passive, and glance reacts and create proper config
[15:59] <yolanda> makes sense?
[16:01] <jamespage> yolanda, I think it does - the current HA approach passed a VIP to signal its in HA mode right?
[16:01] <yolanda> yes
[16:02] <jamespage> yolanda, do we need rabbitmq >= 3.0.0 todo the active/active stuff? I think we might be not 100% sure
[16:04] <yolanda> jamespage, i don't think so, openstack doc says it's tested with 2.7.1
[16:04] <jamespage> yolanda, OK - the setting of HA policy in your change is scoped to >= 3.0.x
[16:05] <yolanda> jamespage, that's only needed for version >= 3.0.x, just followed openstack guide
[16:05] <jamespage> yolanda, ah - OK _ good-oh
[16:06] <yolanda> jamespage, i am starting with glance, to make glance react to rabbit_hosts needed to grab version from precise-havana
[16:06] <yolanda> doesn't seem to work with older versions
[16:20] <zul> Daviey:  when you get a chance can you look at pytyhon-designateclient for me (its in source new, dependency needed for openstack-trove)
[16:45] <hallyn_> rbasak: trusty is not supported by uvt-simplesreams-sync?
[16:48] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769
[16:50] <rbasak> hallyn_: it comes from a different stream. uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily release=trusty arch=amd64 or similar.
[16:50] <hallyn_> rbasak: any reason not to have uvt figure that out?
[16:50] <hallyn_> (lxc-create does :)
[16:51] <hallyn_> (you can see i'm big on not typing more than i need to :)
[16:51] <rbasak> hallyn_: it would be nice, yes. It's a bit of a tricky thing to do with the simplestreams API, and I think it should probably be pushed back there in some way. lxc-create will have the same issue when it's simplestreamed.
[16:53] <rbasak> hallyn_: I'd like to tell the simplestreams API "here are your streams, here are my filters, go". But I'm not sure about how multiple streams will interact that way.
[16:53] <rbasak> smoser: ^^
[16:55] <rbasak> hallyn_: btw, I uploaded the latest PPA earlier
[16:55] <hallyn_> cool, thanks.
[16:59] <jamespage> zul, OK - I think that nova mp is ready to go - ditto the neutron one
[16:59] <jamespage> zul, looking at that now
[16:59] <jamespage> why do we need to disable the tests?
[16:59] <zul> jamespage:  they are broken for now
[17:00] <zul> and we need to do a mir for nose
[17:03] <smoser> rbasak, i dont hink i follow
[17:04] <jamespage> zul, blimey - swift needs some love
[17:05] <jamespage> zul, which bit of nose?
[17:05] <zul> jamespage:  the functional test bits
[17:06] <jamespage> zul, yeah - I mean't which dependency?
[17:06] <zul> jamespage:  hold on lemme double check
[17:06] <smoser> rbasak, com.ubuntu.cloud.daily:server:trusty:amd64 is very explicitly different than com.ubuntu.cloud:server:trusty:amd64
[17:06] <smoser> that is by design.
[17:06] <smoser> i woudln't suggest munging that all together.
[17:07] <zul> jamespage:  libjs-jquery-hotkey, jquery-goodies, libjs-jquery-isonscreen, and javascript-common
[17:07] <jamespage> zul, is that for docs?
[17:07] <zul> jamespage:  i believe so
[17:09] <rbasak> smoser: yes, they are. But uvtool should munge them together, as an exception, for the development release.
[17:09] <rbasak> smoser: this makes them analogous to what people expect by setting their sources.list.
[17:10] <smoser> i dont think so.
[17:10] <smoser> there is no released trusty.
[17:10] <smoser> if you say trusty released, it can't get you such a thing.
[17:10] <smoser> if you say trusty and daily, it can
[17:10] <rbasak> I want the latest available of everything. For stable releases, I want the stable image. For the development release, I want the development release.
[17:11] <rbasak> Sorry. For the development release, I want the latest development image (ie. a daily).
[17:11] <smoser> why?
[17:11] <rbasak> uvt-just-give-me-it.
[17:11] <smoser> that daily might not work at all.
[17:11] <rbasak> That's fine. That's what using the development release means.
[17:12] <rbasak> The CLI should provide sensible defaults. If I specify a release, then the sensible default is the stable release image for stable releases, and the daily image for the development release.
[17:12] <jamespage> zul, sorry - don't get it
[17:13] <rbasak> It is fine for this to be uvtool-specific and Ubuntu-specific. I'm just saying that I want some way to explain this to the simplestreams API.
[17:13] <zul> jamespage:  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[17:13] <rbasak> Or else we need to figure out how uvtool should handle the interaction.
[17:13] <jamespage> zul, there is actually no point in running them - SKIPPING FUNCTIONAL TESTS DUE TO NO CONFIG
[17:13] <jamespage> https://launchpadlibrarian.net/154000942/buildlog_ubuntu-saucy-i386.swift_1.10.0-0ubuntu1_UPLOADING.txt.gz
[17:13] <smoser> i personally dont really think that "daily image for development release, but stable imgaes for all others" is likely whta a developer wants.
[17:14] <smoser> more likely i'd want dailies of everything.
[17:14] <zul> jamespage:  agreed
[17:14] <jamespage> zul, I don't see why that would require disabling tests
[17:14] <smoser> cstack does handles this. sanely.
[17:14] <jamespage> zul, also the swift-doc package is empty
[17:14] <zul> jamespage:  ok ill have a look at getting this fixed then
[17:15] <rbasak> hallyn_: ^^ interested in this conversation?
[17:15] <jamespage> zul, thats a regression - 1.10.0 has it
[17:15] <jamespage> populated
[17:15] <hallyn_> no? :)
[17:15]  * hallyn_ looks
[17:15] <rbasak> smoser: I think you assume that the CLI somehow knows that this is a developer speaking. It doesn't know that.
[17:15] <rbasak> smoser: given that it doesn't know, I think it's reasonable to default to the released image for stable releases.
[17:16] <rbasak> smoser: but given that the user just asked for "trusty", and that there is no released image for that, and it's known to be a development release, I think it's reasonable to provide a daily in that case.
[17:16] <hallyn_> 17:13 < smoser> i personally dont really think that "daily image for development release, but stable imgaes for all others" is likely whta a developer wants.
[17:16] <hallyn_> i disagree.  that's exactly what i want
[17:16] <smoser> its not what i want
[17:16] <smoser> and i'm a developer
[17:17] <hallyn_> it's myworkaround for you cloud image folks being too lazy to give mea  stable devel image
[17:17] <smoser> hallyn_, its not cloud image folks.
[17:17] <smoser> there is no stable devel image of any ubuntu
[17:17] <smoser> when there is (next thursday)
[17:17] <smoser> you'll have something in the stable stream of trusty
[17:17] <hallyn_> that's alpha1?
[17:17] <smoser> it will be correctly labelled 'alpha-1' rather than release
[17:18] <rbasak> I'm happy to add a --developer option that changes sync's default to use the daily stream.
[17:18] <hallyn_> in the end (ignoring smoser's being pedantic) i don't care who builts the smarts in - uvtool or simplestreams.
[17:18] <rbasak> However, ifi the user doesn't do that, I still want trusty to be available by default, on request. And I don't think it's reasonable to default to daily images across the board.
[17:19] <hallyn_> but i wanted to test something in canonical-kernel-team/ppa just now for trusty, and wanted the 'best' trusty cloud image i could find
 i'm with rbasak.
[17:19] <smoser> hallyn_, that would be the dailies ;)
[17:19] <rbasak> So I think "best" is released for stable releases, and daily for development releases, despite any alpha-1.
[17:20] <hallyn_> smoser: i'm just a user of uvtool.  i don't care where it comes from, i just want "the most stable" image that exists
[17:20] <smoser> no you dont.
[17:20] <rbasak> hallyn_: would you want alpha-1 or a daily for trusty, if both existed and the daily were newer?
[17:20] <smoser> so its fine with me if uvtool has logic like:
[17:20] <hallyn_> rbasak: i guess i'd want daily
[17:21] <smoser>  if release_requestsed == ubuntu_development_release(): change_stream_to_daily()
[17:21] <rbasak> smoser: trouble is that right now uvtool just passes through the release=... filter without understanding it.
[17:21] <rbasak> I would prefer to not special case that understanding.
[17:22] <smoser> you want a special case understanding
[17:22] <smoser> but you dont want to special case it
[17:22] <smoser> you want someone else to special case that
[17:22] <rbasak> I want a general way of handling this case.
[17:22] <smoser> but the someone else here thinks that when you say "released" you get "released". and when you say "daily" you get "daily"
[17:22] <rbasak> I'm fine with telling the simplestreams API about this understanding. I want to do it in an API call.
[17:23] <smoser> i dont think so. daily is explicitly and by design not released.
[17:23] <rbasak> If the user specifies released or daily, then that should override default behaviour and do what you asked for.
[17:23] <smoser> you can munge those two things together however you choose.
[17:23] <smoser> as i said, cstack does this "right" for me.
[17:23] <rbasak> If the user doesn't specify released or daily, released/dailiness should be based on the status of the release requested.
[17:24] <rbasak> And of course the release requested should also have a default, but that wouldn't change this behaviour.
[17:24] <smoser> rbasak, then you can implement that.
[17:24] <rbasak> smoser: you want me to parse simplestreams filter rules myself?
[17:24] <rbasak> smoser: I want the simplestreams API to do the parsing, but for me to give it the rule.
[17:26] <smoser> you want 2 completely different things. available only from 2 completely different, completely unrelated sources.
[17:27] <rbasak> Yet the release on one corresponds to the release on another.
[17:27] <rbasak> They are not completely unrelated.
[17:27] <smoser> happenstance
[17:27] <rbasak> No. I have a specific reason for wanting that relation. Therefore, provided that my reason is reasonable, they are related.
[17:28] <smoser> scott james remnant and scott moser are not related.
[17:28] <rbasak> They relate at the CLI. 1) "Trusty!"..."ok, you want daily." 2) "Saucy!"..."ok, you want released."
[17:29] <smoser> even if it would be convenient for robie basak if they were.
[17:29] <rbasak> The names precise, quantal, raring, saucy, trusty are related. The daily images are related to that set. So are the released images.
[17:29] <smoser> just like my example.
[17:29] <smoser> same name
[17:29] <smoser> different thing
[17:29] <smoser> i can't fix your chromebook.
[17:29] <rbasak> The daily ends up being a released.
[17:30] <smoser> happenstance
[17:30] <smoser> honeslyt.
[17:30] <rbasak> Nothing like your example.
[17:30] <smoser> you're welcome to buildin the knowledge that 'com.ubuntu.cloud.daily' is somehow related to 'com.ubuntu.cloud'
[17:30] <rbasak> I think a problem here is that you do not accept the original use case that makes me want this.
[17:30] <smoser> but you have to go to 2 completely different end points of data to find those things.
[17:31] <smoser> i think this is easily solvable.
[17:31] <smoser> and i've told you I'm ok for you to solve it.
[17:31] <rbasak> Well, I can parse the simplestreams filters. So we can duplicate the code, and lock in the simplestreams filter query language. Great.
[17:32] <smoser> you can create filters. and mirror 2 streams to 2 different locations.
[17:32] <smoser> i dont see how that is duplicating anything.
[17:33] <rbasak> I need to do that automatically. Without expecting the user to set it up for me. And I need to handle the transition of a release, where I want to switch from use of a daily image to a released image.
[17:33] <rbasak> Oh look - they're related!
[17:34] <smoser> they're not related.
[17:34] <smoser> was that unclear ?
[17:34] <rbasak> Where I was using a trusty daily image, I will after release want to use a trusty released image. Thus they're related.
[17:34] <smoser> dont handle it.
[17:35] <smoser> after trusty is released, get the released stream
[17:35] <rbasak> The point of uvtool is to hide this complication, and just do what is reasonable.
[17:35] <rbasak> Automatically.
[17:36] <rbasak> The only way I can see of doing this is to either hardcode the assumption that the release key maps between daily and released, or to publish the mapping somehow.
[17:36] <rbasak> (oh look - they're related)
[17:36] <rbasak> I guess we're at an impasse, which basically just means that the pain will continue. Sorry hallyn_.
[17:37] <smoser> cstack does this right.
[17:37] <rbasak> Except that you've defined what you think is right, and we disagree.
[17:38] <rbasak> Somebody who says "precise", without any further information, can be inferred to mean "stable, please". And someone who says "trusty" presumably means "development, please".
[17:39] <smoser> and then based on some even that occurs at some point in the future, your interpretation of what they mean changes.
[17:39] <smoser> which is odd.
[17:39] <smoser> and unexpected.
[17:39] <smoser> just because the calendar says 2014-04-17.
[17:39] <hallyn_> that event being a release?
[17:39] <rbasak> It matches how Debian releases work, so is not at all unexpected.
[17:39] <hallyn_> that's not expected
[17:39] <hallyn_> uh, not unexpected
[17:39] <smoser> it is unexpected to the user.
[17:39] <rbasak> It is not, since that's what the release names are defined to mean.
[17:39] <rbasak> That's how we all use the term.
[17:39] <hallyn_> the user to whomthat is unexpected would nto specify a release at all, and run latest LTS
[17:40] <rbasak> You've invented your own system of daily and released for cloud images (with good reason), but that doesn't mean that these concepts apply to release names.
[17:40] <smoser> it is not good design for behavior to change
[17:41] <smoser> based on events non-controllable by the user
[17:41] <smoser> "I did nothing, yet it broke"
[17:41] <smoser> where "it broke" is "it behaved differently"
[17:41] <rbasak> "I had a bug in Trusty, which I fixed, but why isn't showing up in my uvtool test? Wait, why is it using alpha-1?"
[17:42] <rbasak> The development release is *defined* to behave differently.
[17:42] <rbasak> It is not good design to surprise the user.
[17:42] <hallyn_> would it help if 'uvt-s-s query' showed trusty entries in red for "danger"? :)
[18:04] <smoser> rbasak, i dont know how to solve your problem. with the interface you have.
[18:05] <zul> jamespage:  https://code.launchpad.net/~zulcss/trove/trove-cleanups/+merge/198803
[18:05] <smoser> since you'd have to look at 'release=' which could be 'release~([tT][rR].*)'
[18:05] <smoser> or something else that would match that.
[18:07] <smoser> perhaps you should, being an 'ubuntu' tool, explicitly know certain things about releases, and treat them as releases. rather than just as arbitrary keys.
[18:07] <smoser> ie: uvt-kvm trusty
[18:07] <smoser> rather than
[18:07] <smoser>  uvt-kvm release=trusty
[18:08] <smoser> that is the bit that cstack knows.
[19:27] <d1n0> where does a maas node get its sources.list from?
[19:27] <d1n0> its a pxe boot node, and im getting a 403 error when trying the packages
[19:28] <smoser> d1n0, it can be specified by maas.
[19:28] <smoser> but it should default to archive.ubuntu.com
[19:29] <d1n0> smoser; why would i be getting a 403 though, thats what confuses me
[19:29] <smoser> agreed.
[19:30] <smoser> that is confusing.
[19:30] <smoser> are you able to pastebin it ?
[19:30] <smoser> it == the console log
[19:31] <d1n0> Unfortunately not, because after it gets the 403.. the pxe boot fails and it shuts down.
[19:32] <d1n0> logfile: /var/log/squid-deb-proxy/access.log shows the 403 error
[19:34] <sarnold> d1n0: note that s3 systems return '403' when they mean '404'.
[19:34] <sarnold> it's confusing.
[19:35] <d1n0> hmm, now you confuse me even more.. lol
[19:36] <d1n0> smoser; how can I change what the maas sends over to it? I want it to use a local mirror
[19:36] <smoser> d1n0, it depends on what version of maas.
[19:37] <d1n0> whatever is in 13.10
[19:37] <smoser> but i think in cloud-tools version or saucy, it is in the web ui.
[19:37] <smoser> i think
[19:37] <d1n0> i thought so too, but it looks like they took it out between 12.04 and 13.10
[19:37] <smoser> sarnold, well, its not likely s3 is involved here.
[19:38] <smoser> and to be fair, thats general good practice for security.
[19:39] <smoser> ie, you dont tell the attacker "username not found" you tell them "username/password invalid".
[19:39] <d1n0> editing the node only allows editing the hostname and mac addresses (along with changing the default release)
[19:39] <sarnold> smoser: yeah, s3 seemed unlikely, but an s3 workalike crossed my mind. I figured I'd throw it out ;) hehe
[19:39] <smoser> i do agree it sucks for s3
[19:39] <smoser> mirrors explicitly.
[19:39] <smoser> d1n0, it wouldnt be on the node
[19:39] <sarnold> yeah; it's a reasonable enough position in general. hehe. :)
[19:39] <smoser> it would be somwhere else.
[19:39] <smoser> in d'setting' or something
[19:39] <smoser> settings.
[19:43] <d1n0> changed, now for another attempt at a pxe boot
[19:56] <d1n0> now back to my vague invalid mac address error
[20:14] <d1n0> nothing like getting one or more of your mac addresses is invalid when trying to commission a node :s
[20:20] <zul> adam_g:  ping can you +1 https://code.launchpad.net/~zulcss/swift/1.11.0/+merge/198769 please
[20:20] <adam_g> zul, done
[20:21] <zul> adam_g:  thanks
[20:38] <hxm> hi
[20:39] <hxm> i have a server with many domains and I could want to let the users receive and send emails from their domains, as in example facebook does
[20:39] <hxm> forwarding emails, is that possible without using postfix and all those tools that are hard to set up properly for not get as spam
[20:42] <Demosthenex> so ubuntu LTS 10.04. after booting for FIVE MINUTES no one, not root, no accounts can login. timeout nonstop. ssh with key is ok, it seems to be a password authentication chain issue. ideas on debugging?
[20:48] <Demosthenex> ah, i had to remove smb crap from pam common-auth.
[21:29] <mgw> What is the purpose of the packages at http://archive.ubuntu.com/ubuntu/pool/?
[21:50] <mgw> To answer my question… it seems to host the actual packages pointed to from the various Packages.gz
[21:51] <mgw> There's a package in pool that works fine in precise (python-gnupg), but it's not in Precise's Packages.gz…. other than downloading the .deb, how could that be installed via apt?
[22:15] <smoser> hallyn_, its not perfect, but it bevaves the way you happen to think it should
[22:15] <smoser> https://code.launchpad.net/~smoser/uvtool/sm-features00/+merge/198838
[22:15] <smoser> rbasak, ^
[22:15]  * smoser gone
[22:16] <hallyn_> smoser: don't be angry
[22:16] <hallyn_> :)
[22:49] <hallyn_> smoser: looks perfect


[12:35] <karthick87> any one teaching perl?
[12:45] <nigelb> karthick87: No classes scheduled for the near future
[12:46] <karthick87> Oh fine


[06:50] <TheMue> morning
[08:09] <TheMue> fwereade, rogpeppe: hi
[08:09] <fwereade> TheMue, heyhey
[08:09] <fwereade> rogpeppe, heyhey
[08:10] <rogpeppe> TheMue, fwereade: yo!
[08:12] <rogpeppe> fwereade, TheMue: i was planning to take a swap day today, but the weather is minging
[08:12] <rogpeppe> fwereade: so maybe i won't
[08:13] <TheMue> rogpeppe: understandable
[08:15] <fwereade> rogpeppe, yeah, I haven't quite decided yet myself... I think I'll still be in figuring-it-out mode for a bit
[08:17] <fwereade> I will at least get the rename-kill-die branch in though
[08:17] <fwereade> should be ready, but a full test run will take forever
[08:17] <fwereade> (couldn't figure out how to prevent the sync on open yet, and it's a distinct change anyway...)
[08:19] <rogpeppe> fwereade: i took a little break from juju yesterday, and did a little JSON-compatible encoding i'd been wanting to do for ages: http://go.pkgdoc.org/launchpad.net/goson
[08:20] <fwereade> rogpeppe, cool, I remember you mentioning that idea
[08:20] <rogpeppe> fwereade: it seems to work well
[08:20] <rogpeppe> fwereade: (i forked the go JSON package, so i got the advantage of a pretty good test suite)
[08:21] <rogpeppe> fwereade: see the MarshalIndent example to see how it looks
[08:22] <fwereade> rogpeppe, the example links appear to be broken
[08:22] <rogpeppe> fwereade: i'm going to use it for displaying and editing JSON even if i don't actually store or transmit anything in this format.
[08:22] <rogpeppe> fwereade: hmm, works for me
[08:22] <rogpeppe> fwereade: http://go.pkgdoc.org/launchpad.net/goson#_example_MarshalIndent
[08:22] <rogpeppe> fwereade: you need to click on the Example link inline
[08:23] <fwereade> rogpeppe, yeah; doing so takes me to an arbitrary top level doc for some reason
[08:23] <rogpeppe> fwereade: weird
[08:23] <fwereade> rogpeppe, ah no, it takes me *just* below but doesn't expand
[08:24] <rogpeppe> fwereade: you can also look at the example source: http://bazaar.launchpad.net/+branch/goson/view/head:/example_test.go#L85
[08:24] <fwereade> rogpeppe, just go getting it :)
[08:24] <rogpeppe> fwereade: :-)
[09:17] <rogpeppe> fwereade: now there's a command "goson" - takes goson or json on stdin and produces goson or json on stdout; launchpad.net/goson/cmd/goson
[09:17] <fwereade> rogpeppe, neat :)
[09:26] <rogpeppe> fwereade: goson -indent '' (compact output) reduces json size by 7% on average too. that's quite nice.
[09:26] <fwereade> rogpeppe, sweet :)
[09:36] <rogpeppe> fwereade: here's a nice before/after comparison: before: http://paste.ubuntu.com/1224159/; after: http://paste.ubuntu.com/1224160/
[09:51] <fwereade> rogpeppe, weird, the before doesn't exist
[09:51] <fwereade> rogpeppe, TheMue: btw, I really ought to know what exactly you guys are working on
[09:52] <fwereade> rogpeppe, I am torn between, y'know, fixing what looks like avoidable ugliness and noise in the tests, and doing the RelationUnitsWatcher I think I really *should* be working on
[09:52] <TheMue> fwereade: currently i'm going through the reviews in gustavos last mail
[09:52] <fwereade> rogpeppe, but just convincing myself that what I just merged made the test suite no worse than it was before took a disturbingly long time
[10:39] <rogpeppe> fwereade: i'm working on getting environs/ec2 working live, currently.
[11:37] <fwereade> rogpeppe, cool, I'm sticking with RUW for the time being
[13:29] <TheMue> lunchtime
[13:58] <niemeyer> Good morning!
[14:00] <TheMue> morning
[14:04] <rogpeppe> niemeyer: yo!
[14:04] <rogpeppe> niemeyer: nice work on the plane, BTW
[14:24] <fwereade> niemeyer, heyhey
[14:27] <niemeyer> rogpeppe: Thanks
[16:06] <fwereade> ok, my brain is melted for now... bbl
[16:06] <niemeyer> fwereade: Cheers
[16:07] <niemeyer> I'm just off a meeting, and will grab some lunch
[16:13] <fwereade> GAAAAH
[16:13]  * fwereade now better understands StartSync's place in the ecosystem
[16:13]  * fwereade kinda wants to kick something
[16:14] <fwereade> (it emerges that -- obviously, in hindsight -- just StartSyncing before waiting for a watch is *not* enough if the event you're watching for hasn't happened yet)
[16:19] <TheMue> fwereade: does the current ServiceRelationsWatcher what you expected in https://bugs.launchpad.net/juju-core/+bug/1032539 ?
[16:26] <rogpeppe> fwereade: ah, good point.
[16:26] <rogpeppe> fwereade: i wonder if StartSync should really be SetPollInterval(somethingSmall)
[16:27] <rogpeppe> fwereade: then it won't be so vulnerable to buffering between request and reply
[16:41] <niemeyer> -1 in principle.. the current behavior is pretty great in that it forces races conditions to be visible. I'm pretty sure there were never seen races with zk just because it happened to return fast enough from the watch locally.
[16:42] <niemeyer> The observable delay between action + watch is real
[16:42] <rogpeppe> niemeyer: the problem with StartWatch is that the delay might be >1s
[16:42] <niemeyer> and it'll be even more real in a loaded and distributed system
[16:42] <niemeyer> rogpeppe: Just make the logic deterministic then
[16:42] <niemeyer> rogpeppe: See both the provisioner and the firewaller for examples of it working fine
[16:44] <rogpeppe> niemeyer: i'm wondering if perhaps those are easier because they're making changes directly to the state, whereas (i hypothesize) perhaps some operations on the uniter do not respond to the state directly.
[16:45] <rogpeppe> niemeyer: maybe that's not true though
[16:45] <niemeyer> rogpeppe: I'm sure there are trickier cases waiting to be seen, even if that's not the case now.. I don't think yet that those guarantee a change in the rules, though
[16:51] <rogpeppe> niemeyer: you may well be right. we'll see how things develop.
[16:54] <niemeyer> TheMue: ping
[17:14] <niemeyer> Hmm.. uh oh.. merge race
[17:26]  * rogpeppe is off for the day. see y'all tomorrow.
[17:27] <niemeyer> rogpeppe: Have a good evening man
[20:06] <TheMue> re
[20:06] <niemeyer> TheMue: Yo
[22:08] <fwereade> niemeyer, if you're in the mood for some light reading: https://codereview.appspot.com/6567044/
[22:30] <fwereade> niemeyer, not sure if you saw: https://codereview.appspot.com/6567044/ has a RelationUnitsWatcher (and a few Uniter tests passing)
[22:31] <niemeyer> fwereade: I haven't seen it yet
[22:31] <niemeyer> fwereade: I'm trying to get the uniter tests to pass as-is as well
[22:32] <fwereade> niemeyer, very recent -- but I mentioned it shortly before you timed out
[22:32] <niemeyer> fwereade: Ah, no, I didn't get that, thanks
[22:32] <niemeyer> fwereade: I have a few fixes for the uniter already
[22:32] <fwereade> niemeyer, ah, I was doing more uniter tests on top of that
[22:32] <niemeyer> fwereade: Mainly ports from the specific watches to the entity ones
[22:33] <fwereade> niemeyer, mostly fixing up unit/service watchers
[22:33] <niemeyer> fwereade: Oh, but do you have uniter tests passing yet?
[22:33] <fwereade> niemeyer, ha, we are colliding right now
[22:33] <fwereade> niemeyer, only some so far but it seems healthyish
[22:33] <niemeyer> fwereade: I imagined we could, but I wasn't too worried about having *two fixes* for the uniter :-)
[22:33] <niemeyer> fwereade: I'm about to "time out"
[22:33] <fwereade> niemeyer, ha, yeah :)
[22:33] <fwereade> niemeyer, np, I should too
[22:34] <niemeyer> fwereade: So perhaps I can push a branch for your enjoyment so that you can merge what you find useful, and drop what you don't
[22:34] <fwereade> niemeyer, we can look at the fixes tomorrow :)
[22:34] <fwereade> niemeyer, cool
[22:34] <niemeyer> fwereade: Hold on, I'll send the WIP
[22:34] <fwereade> niemeyer, yes please :)
[22:34] <niemeyer> fwereade: Curious about what you find
[22:35] <niemeyer> fwereade: I was just starting to debug a non-stopping watcher.. but I have to visit a relative that has an injured leg in a bit
[22:35] <fwereade> niemeyer, no worries
[22:36] <niemeyer> Pushing
[22:36] <niemeyer> fwereade: It all works, btw
[22:36] <niemeyer> fwereade: Surprisingly, even the uniter
[22:36] <fwereade> niemeyer, surprisingly?
[22:36]  * fwereade looks smug
[22:36] <fwereade> ;)
[22:37] <niemeyer> fwereade: I did a full deployment of builddb
[22:37] <fwereade> niemeyer, awesome :D
[22:37] <niemeyer> fwereade: Well, considering we did no work after we moved the state, I was expecting it to need tweaks, as we're doing now :)
[22:37] <fwereade> niemeyer, yum yum dogfood ;)
[22:37] <niemeyer> fwereade: I was surprised that it worked despite we not touching it
[22:37] <niemeyer> fwereade: Good job :)
[22:38] <niemeyer> fwereade: https://codereview.appspot.com/6562045
[22:38] <fwereade> niemeyer, sweet, thanks
[22:38] <niemeyer> fwereade: Oops.. I missed the pre-req.. please ignore the changes in unit
[22:38] <fwereade> niemeyer, np
[22:38] <niemeyer> fwereade: These are already up for review in an independent branch
[22:38] <fwereade> niemeyer, cool, I must catch up with those tomorrow
[22:39] <niemeyer> fwereade: Very quickly, did we do the same thing: https://codereview.appspot.com/6562045/diff/1/worker/uniter/modes.go
[22:39] <fwereade> niemeyer, yeah, give or take a var name or two ;)
[22:39] <niemeyer> fwereade: This is awesome.. for awesome, I appreciate the duplication of efforts :-)
[22:39] <niemeyer> s/for awesome/for once
[22:40] <fwereade> niemeyer, haha, yeah :)
[22:42] <niemeyer> fwereade: I know it's late there, but in case you want the no-error unit.Resolved in trunk by the time you wake up, just have a quick look at: https://codereview.appspot.com/6570043/; I'll do required changes and merge when I'm back, if so.
[22:42] <niemeyer> fwereade: Otherwise, we can easily handle it tomorrow
[22:42]  * fwereade looks
[22:43] <fwereade> niemeyer, LGTM, much nicer
[22:43] <niemeyer> fwereade: cheers
[22:44] <niemeyer> fwereade: Bootstraps are working again with trunk, btw
[22:44] <fwereade> niemeyer, excellent
[22:44] <niemeyer> Well, with the branch I'm merging right now
[22:49] <niemeyer> Alright, I'm stepping out..
[22:49] <niemeyer> fwereade: Have a good sleep there
[22:50] <fwereade> niemeyer, cheers, I hope your relative mends soon
[22:50] <niemeyer> fwereade: Thanks!


[19:48] <ScottK> If I'm using git and someone has submitted a merge proposal, where is the documentation on how do the actual merge?
[19:56] <cjwatson> Hm, not sure it's written down.  In general, 'git remote add -f some-new-remote-name lp:~contributor/... && git merge some-new-remote-name/name-of-branch' etc.  (I'd like to have a merge button, but have some more urgent things to sort out with LP git first ...)
[19:57] <cjwatson> Some projects have a merge robot that will respond to you setting the MP's overall status to Approved, but since you're asking I assume you don't have one of those.
[22:26] <ScottK> No.  I don't.
[22:26] <ScottK> Even if you don't have the merge button, it'd help a lot to display the git command to copy/paste.
[22:27] <ScottK> Thanks.


[00:00] <RAOF> dart: Excellent, thanks.
[00:19] <astraljava> RAOF: Perhaps you were thinking of this: https://wiki.ubuntu.com/UbuntuFriendly ?
[00:20] <nemo> Is it ever appropriate to just file a generic compatibility bug for this laptop model and detail the issues and workarounds?
[00:21] <nemo> astraljava: hm. that looks interesting, but doesn't really have a way to submit test data :)
[00:21] <nemo> looks like more an evang operation
[00:22] <astraljava> nemo: Maybe. I thought this to be interesting, though: https://blueprints.launchpad.net/certify-planning/+spec/cert-o-community-testing
[00:23] <RAOF> nemo: No, not really.  In an ideal world, a bug is a single actionable defect in the software.  ‘Some stuff on this laptop isn't working’ should be a single bug iff it's got a single cause (although you obviously can't actually tell until you've fixed it ☺).
[00:24] <nemo> RAOF: ah.  Mozilla's process is a bit more flexible. they have tracking bugs for various initiatives and whatnot
[00:24] <nemo> big ol' bug hierarchies
[00:24] <nemo> but 'k. guess what I'd be looking for is more some sort of Ubuntu on Laptops where I could fill in an entry for my laptop model - much like Wine has a software database where success can be filled out
[00:25] <RAOF> Yeah.  Launchpad doesn't support bug hierarchies in that way, so we don't use them :)
[00:25] <broder> nemo: i think that's what Ubuntu Friendly is supposed to be working towards
[00:25] <broder> though possibly with a little more rigor around what "working" and "not working" mean
[00:25] <nemo> launchpad is annoying in quite a few ways.  one that bugs me most, is no id for each comment, so I can't link to a comment in context
[00:25] <broder> that's not true
[00:26] <RAOF> nemo: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/774938/comments/4
[00:26] <nemo> RAOF: right. that's the annoying bit
[00:26] <nemo> you can link to a specific comment
[00:26] <nemo> but if you want to see it relative to the comments around it, you have to scroll through the list
[00:26] <nemo> there is no <div id="comment54323"> as virtually every other blog and bug db out there has
[00:26] <nemo> so even if I look at the HTML I can't make a #comment54323 link
[00:27] <RAOF> Ah, yeah.  That makes sense.
[00:27] <nemo> of course it really should have an anchor for that purpose
[00:27] <nemo> oh well. has been that way for years, and I think I did complain in a bug once, so isn't likely it'll be fixed any time soon
[00:28] <nemo> broder: well. thanks for the link. I'll keep an eye on that page, and if it ever gets to the point where it accepts user submissions, I'll post my laptops :)
[00:28] <nemo> aaand, guess I'll stick w/ issue-specific bugs for now
[00:45] <cnd> RAOF, bryce, slangasek: I can't reproduce the bug in xorg-server, and it's a fairly simple traditional mouse
[00:46] <slangasek> ok
[00:46] <cnd> since there are no other reports, I'm inclined to think something is awry with his particular setup somehow
[00:46] <cnd> I've asked for some more data in the bug
[00:46] <slangasek> maybe he should try the upgrade again?
[00:46] <cnd> I asked him to upgrade, then play back his own recording
[00:46] <cnd> see if it reproduces
[00:46]  * slangasek nods
[00:46] <cnd> it could be something simple like dying batteries :)
[00:47] <slangasek> cnd: thanks; please keep us posted, but I'm not going to take any precipitous action wrt the published SRU at this point
[00:47] <cnd> I am off tomorrow :(
[00:47] <cnd> but I'll try to monitor it
[00:47] <slangasek> is there someone else who can take it over from you?
[00:48] <cnd> I would say anyone of the top dogs of ubuntu-x would be best equipped
[00:48] <cnd> tjaalton, bryce, or RAOF
[00:48] <cnd> it's not multitouch related, so it's not really in the realm of anyone else on the touch team
[00:49] <cnd> forgot about Sarvatt :)
[00:52] <RAOF> Ok.  I'll monitor it today and pass off to bryce or tjaalton in the evening.
[00:52] <RAOF> cnd: Have a good day off tomorrow!
[00:52] <cnd> RAOF, thanks!
[00:53] <tjaalton> actually, I'm off for the rest of the week ;)
[00:53] <cnd> tjaalton, then have fun too!
[00:53] <tjaalton> but yeah, sounds like a dead battery or such
[00:53] <tjaalton> cnd: thx!
[01:06] <bryce> ok
[02:42] <slangasek> hallyn: closing bug #773891 as invalid; you don't appear to be subscribed, so thought I'd let you know
[02:43] <hallyn> slangasek: drat, i thought i'd subscribed by habit.  Thanks much!
[02:44] <hallyn> looks like i need to look at a multi-ach converted library so I know what to look for
[03:21] <broder> https://wiki.ubuntu.com/UbuntuEmail
[03:21] <broder> err, wrong window
[03:32] <sivan> hi all
[03:32] <sivan> Is there anybody from the Montreal office?
[03:32] <sivan> *here
[04:00] <lifeless> kees: hi
[04:00] <lifeless> hmm perhaps too late for you
[04:00] <lifeless> micahg: I seem to recall you're in the security team ?
[04:53] <micahg> lifeless: yes
[04:54] <lifeless> micahg: oh cool
[04:54] <lifeless> micahg: bug 791652 may interest or terrify you
[04:55] <micahg> lifeless: fun :)
[04:55] <micahg> lifeless: are you sure that /tmp isn't in $PATH?
[04:55] <lifeless> /home/robertc/local/bin:/home/robertc/bin:/home/robertc/local/bin:/home/robertc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[04:56] <lifeless> micahg: its not there in the environment I run from for sure
[04:56] <lifeless>  set | grep LD
[04:56] <lifeless> $
[05:02] <micahg> lifeless: BTW, I failed to note it was private until after I posted the first reply to you, I guess I'm not used to the bar on top yet :-/
[05:02] <lifeless> hmm
[05:02] <lifeless> :(
[05:03] <micahg> the benefit on the bar on the side was that you could see it all the way down the page, my eyes went straight to the description
[05:03] <lifeless> thats worth noting on the bug I think
[05:11] <lifeless> micahg: found it
[05:12] <micahg> lifeless: the solution to your problem?
[05:12] <lifeless> no
[05:12] <lifeless> the utterly insane code.
[05:12] <micahg> ah, cool
[05:12] <lifeless> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/791652/comments/2
[05:13] <lifeless> I expect at least an OMFG in about 5 seconds
[05:13] <micahg> lol
[05:14] <ScottK> This bug not found thing.  I've hit it before, but never when I had a chance to investigate at all.
[05:15] <micahg> ScottK: it's a private bug
[05:15] <lifeless> ScottK: security / private bugs
[05:15] <lifeless> ScottK: also bug numbers we don't allocate
[05:15] <lifeless> which happens if a file-a-bug transaction rollsback
[05:15] <ScottK> I see.
[05:15] <ScottK> So maybe mine was something different.
[05:19] <lifeless> anyhoo
[05:19] <lifeless> having found that, I'm off to do something completely different :)
[05:19] <StevenK> ScottK: 403 and 401 both give the idea that something is there, but you can't see it. 404 doesn't.
[05:22] <ScottK> Right.  In the case I had I got bugmail that said I'd been mailed because I was subscribed to a duplicate bug.  Then when I went to the primary bug and clicked on the named dup, I got the 404 reply.
[05:23] <StevenK> Right, that is a bug
[05:23] <lifeless> no
[05:23] <lifeless> its deliberate
[05:23] <ScottK> Ah.  So I'm trapped in bugmail hell forever?
[05:23] <StevenK> We shouldn't say "Duplicate of private bug" ?
[05:24] <lifeless> oh
[05:24] <lifeless> let me rephrase
[05:24] <ScottK> The primary bug wasn't private.
[05:24] <lifeless> the 404 is deliberate
[05:24] <lifeless> the behavior of apport duping bugs onto a private bug is a bug
[05:24] <lifeless> and launchpad permitting that is also a bug
[05:24] <ScottK> Agreed.
[05:24] <ScottK> This wasn't that case.
[05:24] <lifeless> let me get some references
[05:24] <lifeless> well, dups across privacy boundaries are problematic
[05:25] <StevenK> Agreed
[05:25] <lifeless> ScottK: we shouldn't be linkifying those dupes now, and arguably we shouldn't even show them to you if you can't see them
[05:25] <lifeless> we kindof have to when bug A that you can see is a dup of bug B that you cannot see.
[05:25] <ScottK> Right, but I could see the primary and was subscribed to the dupe.
[05:26] <lifeless> ScottK: then you should have been able to see the dupe
[05:26] <ScottK> Agreed.
[05:26] <lifeless> ScottK: so something else happens
[05:26] <ScottK> That's why I think it was a bug.
[05:26] <lifeless> maybe someone unsubscribed you from the dupe between you looking at the master and clicking on the link
[05:26] <ScottK> Possible in theory, but highly unlikely I think.
[05:27] <lifeless> anyhow, bugs in this sort of space - bug 764414 bug 434733 bug 136570 bug 262280
[05:28] <lifeless> I realise these don't match your exact situation
[05:28] <ScottK> I may have to just apply my Rosetta mail policy to bug mail.  I'm getting a bit tired of stuff I can't keep out of my inbox.
[05:28] <lifeless> ScottK: are you in the new bug mail beta ?
[05:28] <ScottK> lifeless: I'm not.
[05:28] <lifeless> ah
[05:29] <lifeless> well it should be live in a few days
[05:29] <ScottK> Does it deal with the case when I'm subscribed to a bug due to a team and I want to make the mail from that bug stop without affecting other team members?
[05:29] <ScottK> That's the one I primarily need.
[05:30] <lifeless> yes
[05:30] <lifeless> you click on 'mute'
[05:30] <StevenK> ScottK: Did you see jml's lightning talk at UDS?
[05:30] <ScottK> I saw about half of it.
[05:31] <StevenK> ScottK: I'd suggest re-watching it, it explains the new bug subscription stuff quite well.
[05:32] <ScottK> Well I think lifeless answered my immediate question.  If it can do that it's at least an 80% solution for me.
[05:34] <broder> hmph. dch changes broke backportpackage. bdrung, i'm blaming you :-P
[05:37] <broder> ah, he fixed it already, my daily builds are just a few days behind. carry on :)
[06:48] <kees> lifeless: gee, that's delightful. upstream silently fixed it in 3.3.0.
[06:54] <lifeless> woo
[06:54] <syn-ack> you the same lifeless from Undernet?
[06:55] <lifeless> many many many years ago I was
[06:55] <syn-ack> Oh, my god.
[06:55] <syn-ack> lifeless, How's it goin' dude?
[06:55] <lifeless> its someone else these days
[06:56] <syn-ack> You're the one I thought you were.
[07:28] <Sensiva> Hello, When will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
[07:58] <didrocks> good morning
[08:13] <hrw> morning
[08:13] <hrw> StevenK: do I assume correctly that you are archive admin today?
[08:13] <StevenK> hrw: I can be.
[08:14] <StevenK> hrw: What do you need?
[08:14] <hrw> StevenK: my package gcc-4.6-armel-cross is in NEW queue. I can answer any questions related to it
[08:14] <hrw> StevenK: lack of it makes whole armel cross toolchain not installable (gcc 4.4/4.5 cross, binutils cross are already in archive)
[08:15] <Sensiva> Does anyone know when will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
[08:21] <StevenK> hrw: Accepted.
[08:22] <hrw> thank you StevenK
[08:39] <bdrung> broder: backportpackage was broken, but the newer dch reveals it. it's fixed in u-d-t trunk
[13:43] <el7r> hi
[16:07] <dantti_> cjwatson: hi, I'm trying to use debconf to display conffile questions in packagekit, but subst() does not allow newlines (so I can show a diff), is there any other command that I can use to set the extended description?
[16:18] <ScottK> dantti_: cjwatson is on holiday this week.
[16:18] <dantti_> ScottK: k, thanks :)
[16:39] <jdstrand> hallyn: hi! I haven't forgotten about libvirt-- though am I right in remembering that you wanted to supply a new package? anyway, I have another question: do you have any scripts for testing qemu-kvm?
[16:40] <hallyn> no i don't.  i (or someone) need to get the kvm autotests going
[16:40] <hallyn> it always gets stalled on not having dedicated hw for it
[16:40] <jdstrand> hallyn: fyi, I came across this: http://wiki.qemu.org/Planning/0.14/Testing
[16:41] <hallyn> jdstrand: i do need to redo the package, just for -v, but nothing major
[16:41] <jdstrand> hallyn: don't bother then, cause I need to add a patch
[16:41] <hallyn> did you get my qa-regession_test patch?
[16:41] <hallyn> ok
[16:42] <jdstrand> hallyn: I like your patch to qrt btw (untested). I think I'd like to make it release specific though
[16:42] <jdstrand> hallyn: I'll handle that too, as I will be fiddling with the script
[16:42] <hallyn> cool thx
[16:59] <nemo> based on what RAOF and astraljava said yesterday, I filed bug #791898 and bug #791900
[16:59] <nemo> oh and bug #791904
[17:00] <nemo> the mouse problem is probably bug #771716, so I just left a comment there.
[17:00] <nemo> it'd be nice to be able to link to all 4 in some sort of laptop database though
[17:00] <nemo> just so others would know what to expect with this model
[17:00] <nemo> hopefully ubuntu has one, someday
[17:05] <dFshadow> anyone know their way around the twitter and facebook APIs?
[17:06] <dFshadow> nvm...found their dev chans on freenode
[17:07] <maco> dapper's eol...time to take it out of the support list
[17:19] <hrw> doko: sent eglibc merge request to fix armhf cross build
[17:19] <hrw> have a nice rest of day people
[17:40] <micahg> hi doko__ , I was wondering if you intended the libreadline5-dev rename to be a full transition to either the new package or libreadline6 depending on licensing or if you just wanted the DM/DD to fix it themselves on demand (in which case we should remove the binary libreadline5-dev so that the Provides in the new package works)
[18:06] <barry> @pilot in
[18:53] <mdz> cjwatson, slangasek, kees, Keybuk, TB meeting shortly
[18:53] <Keybuk> mdz: ack
[18:55] <slangasek> mdz: am I on the agenda today?
[18:55] <mdz> slangasek, no, my mistake, sorry
[18:55] <slangasek> ok :)
[20:51] <smoser> offlineimap recently broek for me in natty (i think this week sometime). I can "fix" it by invoking it with python2.6.
[20:52] <soren> smoser: In Natty? Really? It works fine for me.
[20:52] <soren> smoser: How does it fail?
[20:52] <smoser> i'm guessing somethign recently changed /usr/bin/python -> /usr/bin/python2.7 but it seems like python-defaults is the same in oneiric as in natty
[20:52] <smoser> s/natty/oneiric/ above, soren, sorry.
[20:52] <soren> Ah.
[20:52] <soren> Yeah, python changed.
[20:52] <soren> 2.7.1->2.7.2rc1.
[20:52] <soren> I have a couple of other things that broke that I haven't completely untangled yet.
[20:53] <smoser> so should i open bugs against python?
[20:53] <soren> Depends.
[20:53] <soren> I'd probably start by filing it against offlineimap and go from there.
[20:54] <smoser> well definitely something broke this week, surely that was not expected in a minor release bump
[20:54] <soren> It might be depending on an implementation detail of earlier python versions. That's certainly the case in at least one of the places where I've seen breakage.
[20:54] <smoser> fair.
[20:54] <soren> smoser: Do you have a traceback?
[20:54] <smoser> no.. offlineimap catches them for me :)
[20:55] <smoser> and gives error messages. but its easily recreatable. i've just not dug at all until now.
[20:55] <ScottK> smoser: File a bug and ping barry.
[20:58] <barry> hi smoser.  we'd definitely like to track those problems down asap.  if they are related to upstream 2.7.2 we have about a week to address them before 2.7.2 final (currently scheduled for 11-june)
[20:59] <smoser> nice. i just noticed my apport windows says I "Upgraded to oneiric on 2010-11-15 (198 days ago)"
[20:59] <smoser> barry, bug coming.
[20:59] <soren> barry: I have one for you.
[20:59] <soren> barry: bug 791221
[20:59] <barry> smoser, soren cool.  i'm patch piloting today so it's perfect timing :)  let me finish this upload and i'll take a look
[21:00] <micahg> smoser: that's bug 788936
[21:00] <smoser> wait...
[21:00] <smoser> $  dpkg-query --show python-minimal
[21:00] <smoser> python-minimal	2.7.1-0ubuntu5
[21:01] <soren> What about python2.7?
[21:09] <smoser> barry, bug 792043
[21:10] <barry> smoser: ack
[21:10] <smoser> soren, why did you say '2.7.1->2.7.2rc1.' ?
[21:11] <smoser> my apt-cache policy shows nothing of that sort.
[21:11] <soren> It's lying to you or severely out of date.
[21:11] <soren>  python2.7 | 2.7.2~rc1-2 |       oneiric | source, amd64, i386
[21:16] <smoser> hm...
[21:16] <soren> forget about python-minimal.
[21:17] <smoser> yeah
[21:17] <smoser> $ dpkg-query --show python2.7-minimal
[21:17] <smoser> python2.7-minimal	2.7.2~rc1-2
[21:17] <smoser> where that provides /usr/bin/python2.7
[21:17] <soren> Right.
[21:18] <soren> barry: Would it help if I set up a test system where you could see the failure?
[21:19] <barry> soren: think that would be easier than setting up a vm to test it in?
[21:20] <soren> barry: Not if you can do that easily. It's just a few steps to make it happen.
[21:20] <barry> soren: okay cool.  i can do it fairly easily.  i'll ping you if i run into trouble (finishing up something else here first)
[21:22] <soren> barry: On an oneiric system, do "apt-get build-dep nova; apt-get install bzr ; bzr branch lp:nova ; cd nova ; bash run_test.sh -N" and you should see it happen.
[21:23] <barry> soren: cool.  i have an oneiric vm all set up that should be easy to test on
[21:23] <soren> barry: Wicked. In the mean time I'll see if I can untangle this and come up with a simple test case just for this.
[21:23] <barry> soren: cool
[21:27] <kirkland> is the Oneiric desktop live image working for anyone inside of KVM?
[21:27] <kirkland> hallyn: ^ ?
[21:28] <hallyn> haven't tried
[21:28] <hallyn> trying to figure out why Package.gz doesn't seem to match the contents of pool/main/
[21:28] <hallyn> (presumably i'm misreading the kernel package names/versions)
[21:29] <soren> hallyn: What's the (supposed) discrepancy?
[21:30] <hallyn> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb  vs pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb
[21:30] <hallyn> i'm sure i'm looking at the wrong thing, somewhere
[21:32] <soren> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb is oneiric. pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb is natty
[21:32] <hallyn> doh!
[21:32] <hallyn> i forgot about oneiric :)  thanks
[21:32] <barry> soren: this entry in 2.7's Misc/NEWS file looks suspicious.  there's no bug number so i need to track this down to find out exactly what changed:
[21:32] <barry> - Correct lookup of __dir__ on objects. Among other things, this causes errors
[21:32] <barry>   besides AttributeError found on lookup to be propagated.
[21:32] <barry>
[21:32] <soren> barry: Yep, found that too.
[21:33] <soren> barry: It looks intentional, so I sort of got the impression it was more of a bugfix than anything else.
[21:33] <barry> soren: then, bad python developer!  you didn't include a issue #!
[21:33]  * barry -> #python-dev
[21:33] <hallyn> kirkland: firing off testdrive
[21:34] <kirkland> hallyn: i tried cirrus, vga, and vmware
[21:34] <kirkland> hallyn: cirrus is completely broken
[21:34] <kirkland> hallyn: sorry, ubuntu desktop is completely broken on cirrus
[21:34] <kirkland> hallyn: gets slightly further with std and vmware
[21:34] <kirkland> hallyn: but still not functional
[21:34] <kirkland> hallyn: i suspect its unity 2d issues
[21:34] <micahg> kirkland: unity2d should work with vga
[21:35] <micahg> at least it does in natty
[21:35] <kirkland> micahg: right, i'm talking oneiric
[21:49] <soren> barry: http://paste.ubuntu.com/617043/ reproduces it
[21:50] <ScottK> soren: Is rpc.CnnsumerSet in line 10 a typo?
[21:50] <ScottK> Cnn/Con maybe?
[21:50] <soren> ScottK: Sorry, yes. But that's not the problem :)
[21:51] <soren> Hang on, I have a better test.
[21:51] <ScottK> Sure.  Just wanted to make sure the test case was good.
[21:51] <soren> ScottK: Thanks :)
[21:52] <soren> There:
[21:52] <soren> http://paste.ubuntu.com/617048/
[21:52] <soren> A completely novaless test case.
[21:53] <soren> pymox makes my head spin.
[21:57] <soren> If I add a __dir__ method to the MockAnything class (simply returning an empty list), everything is fine.
[21:57] <soren> barry: ^
[21:58] <soren> barry: Again, I just don't have the expertise to say if pymox is depending on cpython specifics or if this is a bug introduced in Python 2.7.2.
[21:59] <barry> soren: don't worry.  just update the lp bug with what you know and i'll track it down in pythonland
[22:00] <soren> *hugs*
[22:00] <barry> :)
[22:02] <soren> barry: Updated the bug on Launchpad and on Google Code with the test case.
[22:02] <barry> soren: thanks!
[22:02] <soren> barry: Oh, thank *you*!
[23:31] <jdstrand> hallyn: fyi, I am working on a test-qemu.py qrt script. I should have something to check in tomorrow
[23:31] <jdstrand> hallyn: it isn't complete, but is a good start
[23:37] <TheMuso> barry: Are you still piloting?
[23:37] <hallyn> jdstrand: awesome
[23:37] <barry> TheMuso: i'm about to get some dinner, but if there's something easy you need i can help out afterward
[23:37] <TheMuso> barry: No thats fine, I was looking to start my shift, just wanted to make sure we didn't clash.
[23:38] <TheMuso> on items in the queue.
[23:38] <barry> TheMuso: ah, nope, in fact i'll pilot out now
[23:38] <barry> @pilot out
[23:38] <maco> i have something easy if one of you want to sponsor an sru upload
[23:38] <TheMuso> Ok thanks.
[23:38] <TheMuso> @pilot in
[23:38] <TheMuso> maco: I'm on duty now so shute.
[23:38] <TheMuso> shoot even
[23:39] <maco> https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/790960/+attachment/2149841/+files/lintian_2.4.3ubuntu3.debdiff    debdiff for lintian in maverick so debuild -S on maverick for a package-to-be-uploaded-to-oneiric doesn't bomb out on lintian not knowing what the hell oneiric is
[23:39] <TheMuso> maco: Thanks, will look at it now.
[23:40] <maco> thank you
[23:43] <TheMuso> maco: You haven't filled out the paperwork? i.e updated the bug with rationale, possible regression potential etc in the bug for SRU purposes?
[23:43] <micahg> TheMuso: can you ack the packagekit sync?
[23:43] <TheMuso> I don't doubt that the change is small and minor, but I'd say the upload will be rejected without that info.
[23:43] <TheMuso> micahg: Next in line.
[23:43] <micahg> TheMuso: thanks
[23:44] <TheMuso> maco: And the version should probably be ubuntu2.1 as well/
[23:45] <maco> TheMuso: the lintians in natty & oneiric are a different upstream version, so it cant clash with anything anyway
[23:45] <maco> (filled in the SRU points now too)
[23:45] <TheMuso> maco: Fair enough re version.
[23:46] <TheMuso> maco: Ok looks good to me, will test build and upload if all looks good.
[23:46] <maco> k thanks
[23:46] <micahg> TheMuso: maco; that version is already in the archive, please use 2.1
[23:47] <maco> micahg: it is? rmadison says 2.4.3 is only in maverick
[23:47] <micahg> maco: https://launchpad.net/ubuntu/+source/lintian/2.4.3ubuntu3
[23:47] <maco> well and lucid backports with ~lucid1
[23:47] <micahg> maco: it's not just what's in there currently, but everything
[23:48] <TheMuso> micahg: Good catch, I was about to check that myself but you beat me.
[23:48] <maco> doh. ok.
[23:48] <TheMuso> maco: Nvm will change locally.
[23:48] <maco> TheMuso: want me to re-gen, or want to just change it?
[23:48] <maco> ok
[23:48] <TheMuso> Don't worry about another diff.
[23:48] <maco> that was already the second diff. first one didnt have "-proposed"  .... and this is why im not a core-dev
[23:49] <TheMuso> Whenever I deal with SRUs, I stic to a hard and fast .1 version rule, usually safest.
[23:50] <maco> this either means i need to do more SRUs (for practice) or fewer SRUs (so i mess up less) :P
[23:51] <TheMuso> maco: Uploaded, thanks for your work.
[23:51] <maco> thanks luke
[23:52] <TheMuso> micahg: Is the packagekit sync in the sponsors queue? If so, I'll dig it out from there.
[23:52] <TheMuso> seems so
[23:52] <TheMuso> i.e packagekit sync in queue./
[23:52] <micahg> TheMuso: yeah, I did a test build and verified the changes, but am not core-dev
[23:53] <TheMuso> micahg: np wilp verify myself to be sure.
[23:53] <TheMuso> will
[23:53] <micahg> TheMuso: of course :)
[23:54] <slangasek> TheMuso, maco: the security team has some guidance on SRU versioning, linked from the SRU wiki page: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[23:55] <TheMuso> micahg: Just noticed something in the debian changelog for packagekit, something to do with depending on xulrunner or firefox. Is that likely to break anything for us if we take that wholesale?
[23:56] <micahg> TheMuso: it should be an alternate depends (which is needed for the browser plugin) (xulrunner-dev | firefox-dev)
[23:56] <TheMuso> Ok will check that once test built.
[23:56] <micahg> it works since only firefox-dev is in main
[23:57] <micahg> although, now that I think about it, I think that invalidates my test :-/


[12:52] -SwissBot:#xubuntu-devel- ::xubuntu-default-settings:: Apply translations in pt @ https://github.com/Xubuntu/xubuntu-default-settings/commit/2da26ac158c584b0250e88b031faaabf9e12dd7d (by transifex-integration)
[15:45] <ochosi_> DarkTrick: always feel free to create github issues for Greybird - that way there's a higher chance I'll notice
[20:02] <DarkTrick> ochosi, Thank you for the info! I created a github issue


[06:22] <scampydo> Whats better debian or redhat
[13:10] <Ben64> LFS in #ubuntu refusing to ...
[13:11] <Ben64> well thats what thats about
[13:30] <k1l> jbertrand seems to be kind of a timebomb :/
[19:56] <IdleOne> thought jackjl was banned
[19:58] <IdleOne> jacklk*
[22:08] <Slart> Hello.. ricks might becoming a bit of a problem in #ubuntu .. could someone look into it?
[22:09] <k1l> ok, i will take alook Slart . thank you
[22:10] <Slart> thanks


[02:19] <Omnifrog> we are all doomed http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone
[02:36] <wrst> Omnifrog: I read that earlier today
[02:36] <wrst> and how are you doing?
[02:54] <Omnifrog> busy as all get out
[02:54] <Omnifrog> damn leaf falling season
[03:48] <wrst> we just let them rot :)
[03:53] <Omnifrog> if only I didn't rent
[03:54] <wrst> ahh
[03:54] <wrst> that makes a difference and we really don't have many they generally blow away
[15:16] <twayneprice> wrst: My son just ordered the Moto X https://republicwireless.com/
[15:22] <wrst> those phones get really good reviews... I'm awaiting my nexus 5 twayneprice
[15:24] <wrst> I'm trying to stay unlocked on phones from here on out if possible
[15:25] <twayneprice> I kinda don't like that they have a special rom though.
[15:27] <wrst> I don't really eithere
[15:27] <wrst> but I understand why they do but I'm not a fan of that
[15:27] <wrst> and being device locked
[15:28] <twayneprice> They are working on making their stuff an installable app, though.  https://community.republicwireless.com/thread/16706
[15:28] <wrst> ting has hinted that hey may be working on a similar type offering
[15:28] <wrst> but I like what both companies are doing as they are certainly shaking things up
[15:29] <wrst> and I have had surprisingly good service from sprint
[15:29] <wrst> I get 4G from Algood to my house now I think they have just upgraded a bit
[15:43] <twayneprice> I agree.
[15:49] <wrst> I have had 4G since I moved but now it seems to be getting better
[15:50] <wrst> I don't use it much but its nice to have, and I'm getting speeds just as good as verizon, of course as my brother put it probably me and 2 other people are currently using sprint in the area
[15:52] <twayneprice> :)  I'm anxious to try out the Moto X when he gets it.
[15:52] <wrst> I was tempted to go that route they are nice looking phones, but the nexus 5 price /specs are really hard to beat
[15:55] <twayneprice> I'm really curious to check out the service.  We bought some land on the Overton/Pickett county line and my ATT doesn't work.
[15:55] <wrst> will republic roam on other cdma networks?
[15:58] <twayneprice> That is my understanding.
[15:58] <wrst> you should be good then
[15:58] <wrst> north of livingston I have no data, but I do have voice/text via sprint or verizon/us cellualar
[16:00] <twayneprice> I believe that I will be able to roam data too.
[16:42] <wrst> oh wow if you can roam data that's a game changer
[16:52] <twayneprice> https://community.republicwireless.com/thread/1818
[16:53] <wrst> oh wow
[16:53] <wrst> hmm
[16:55] <twayneprice> No tethering, though.
[17:20] <wrst> I have tethering and they actually have forums on how to hack yoru phones if you need help, I like that aspect of ting
[17:20] <wrst> but I'm way more than 20 bucks per month however
[18:02] <twayneprice> I probably won't tether too much anyway since the way they keep the price down is to assume that you will be using wifi mostly.
[18:02] <twayneprice> http://lifehacker.com/most-popular-pre-paid-cellphone-carrier-republic-wirel-1463078932
[18:05] <wrst> yes I had been keeping track of that, actually got a pair of ting sunglasses coming my way for participatiing, actually for commenting in a facebook post
[18:14] <twayneprice> That's pretty cool.
[18:14] <wrst> yes they have been a super cool company to deal with and their phone selection is pretty good
[18:14] <wrst> especially with the possible addition of an iphone
[18:17] <twayneprice> Yea, I've kinda been going back and forth between them a RW.
[18:18] <wrst> my biggest pro ting thing at the moment, is the nexus 5, I can easily switch to another network if need be, other than verizon
[18:23] <twayneprice> I've heard it is pretty nice.
[18:25] <wrst> yes I really like that... now just waiting, waitiing, waiting... to get it


[19:42] <rjbs> Hi.  I'm the project lead for Perl 5, and we've seen a surprising change in the behavior of pathconf(2) on Ubuntu 12.4.
[19:42] <rjbs> Is this an appropriate place to ask for more information?