[01:18] <awwa> hi, what binary launches the HUD in unity2d?
[04:33] <bschaefer> thomi, hmm do you know why jenkins hasent ran since my last push?
[04:34] <thomi> nope, but I can poke it if you like
[04:34] <bschaefer> that would be awesome
[04:34] <bschaefer> I just want to get the video of the ibus-setup thing, I guess ibus-daemon doesn't autostart for unity
[04:35] <thomi> OK, it's running now
[04:35] <bschaefer> thanks!
[04:36] <bschaefer> also just got a VM up, from the daily build. Im hoping I can reproduce it on here...
[04:36] <thomi> cool!
[04:41] <bschaefer> I think Ill parse that install list to install all of those on my VM hm that'll be fun
[04:45] <thomi> bschaefer: so I got the PXE CD built, but now I've hit another roadblock: I can't figure out how to get virtualbox PXE botting working correctly
[04:45] <bschaefer> :(
[04:45] <thomi> I'm half way there, but it doesn't find the correct PXE config file :-/
[04:46] <bschaefer> that's weird I've had to change a setting before but that was PAE I think
[04:46] <thomi> the documentation is worse than useless
[04:47] <thomi> it starts the boot process, then fails when it can't find the config file
[04:47] <bschaefer> what VM are you using?
[04:47] <bschaefer> VirtualBox?
[04:47] <thomi> yes
[04:48] <bschaefer> that's weird, I can try to set up a PXE as well
[04:48] <thomi> it should be simple - I'm sure I'm doing something really basic wrong
[04:49] <bschaefer> have you set up the network?
[04:49] <thomi> all you should have to do is create a folder in ~/.Virtualbox called 'PXE'
[04:49] <bschaefer> so you can ssh into it?
[04:49] <bschaefer> o really?
[04:49] <thomi> then put the .pxe file in called "vm_name.pxe"
[04:50] <thomi> see: https://www.virtualbox.org/manual/ch06.html#nat-tftp
[04:50] <bschaefer> thomi, hmm Im reading this other thing that says you have to change your boot order
[04:50] <bschaefer> under settings, so the network boots first
[04:50] <thomi> you need to do that also
[04:51] <thomi> yeah
[04:51] <thomi> and the Intel network driver doesn't work so well for some people
[04:53] <bschaefer> hmm that's odd. Have you gotten the image installed?
[04:53] <bschaefer> or does it just fail now when you try to boot into it
[04:53] <bschaefer> thomi, also did you install guest additions?
[04:54] <thomi> bschaefer: you can't - no OS until it boots
[04:54] <bschaefer> o dam...
[04:54] <thomi> anyway, I'm 99% sure it's just a configuration issue on the host machine
[04:54] <bschaefer> what if you changed the boot order to get into the OS
[04:54] <bschaefer> could be
[04:55] <thomi> there is no OS
[04:55] <thomi> there's no disk even
[04:55] <thomi> it's a diskless VM
[04:55] <bschaefer> ooo, ok
[04:55] <thomi> :)
[04:55] <bschaefer> under your network settings have enabled a second adapter?
[04:56] <bschaefer> I had to enable a second one to ssh into my VM, so maybe you'll have to add an adapter
[04:57]  * bschaefer is not that good with networks
[04:57] <bschaefer> haha
[04:57] <bschaefer> Im trying to get better, there is always so much to learn
[05:01] <bschaefer> thomi, https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/27/
[05:01] <bschaefer> umm did some test pass??
[05:03] <thomi> that's odd. More likely some tests were removed
[05:03] <thomi> ...or skipped
[05:03] <thomi> the test results UI is pretty confusing though
[05:03] <bschaefer> hhhhmmmmmmmmm it says fixed
[05:04] <bschaefer> some do, also there appears to be active input methods in the engine list!!
[05:13] <bschaefer> thomi, WTF!! https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/27/label=1EBEE0FF-DAC9-11DF-BBDA-64A98C34D485/artifact/artifacts/autopilot.tests.test_ibus.IBusTestsHangul.test_simple_input_hud%20%28transmission%29.ogv
[05:14] <thomi> bschaefer: O.0
[05:14] <thomi> what's that test failing on?
[05:15] <bschaefer> https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/27/label=1EBEE0FF-DAC9-11DF-BBDA-64A98C34D485/testReport/autopilot.tests.test_ibus/IBusTestsHangul/test_simple_input_hud_transmission_/?
[05:15] <bschaefer> incorrect string
[05:16] <bschaefer> odd, but why is it typing...
[05:16] <bschaefer> I can't find which video where the first test_ibus_setup activates the first engine...
[05:16] <bschaefer> some of the videos show an active engine also
[05:21] <bschaefer> thomi, oooo i think I have an idea on whats going on
[05:21] <thomi> o rly?
[05:21] <bschaefer> open ibus-setup
[05:21] <bschaefer> and go over a tab
[05:21] <bschaefer> and remove all the active engines
[05:22] <bschaefer> and you see that checkbox at the top?
[05:22] <bschaefer> check it
[05:22] <thomi> yup
[05:22] <bschaefer> Customize active Input Method
[05:22] <thomi> it was for me already
[05:22] <bschaefer> really?
[05:22] <thomi> yep
[05:22] <bschaefer> so it should be off now
[05:22] <thomi> oh ok
[05:23] <bschaefer> let me run a test. What I think it does is lock the active engines
[05:23] <thomi> ahhh, you think that checkbox is cleared on the jenkins instance?
[05:23] <bschaefer> but if you have none you cant add any
[05:23] <bschaefer> yeah
[05:23] <thomi> worth a shot - we can set that checkbox to ON on as part of the ibus emulator
[05:23] <bschaefer> and my stupid test-ibus-setup went stupid and unchecked it
[05:23] <bschaefer> ooo
[05:23] <bschaefer> sweet
[05:23] <bschaefer> let me double check with a test to confirm that it fails
[05:25] <bschaefer> thomi, yay it failed the same way
[05:26] <bschaefer> Ill look at setup.py to see how to set that on/off
[05:26] <thomi> \o/
[05:26] <bschaefer> main.py
[05:26] <bschaefer> haha
[05:26] <thomi> yeah
[05:27] <thomi> it'll be something in the config - we just need the section name and config option name
[05:28] <bschaefer> ok, hopefully I can find it :)
[05:29] <thomi> I think I found it...
[05:29] <thomi> I thin it's preload_engine_mode
[05:29]  * thomi is testing
[05:30] <bschaefer> alright, I need to get better at finding those, I had a file opened once that had those but now I can't find it haha
[05:31] <thomi> yup, that seemed to do the trick. I'll patch the ibus-testing branch
[05:31] <bschaefer> sweet!
[05:31] <bschaefer> do you want to remove my function?
[05:32] <bschaefer> it does some odd stuff...
[05:33] <bschaefer> thomi, where did you find that preload_engine_mode? Im greping the entire ibus directory and cant find it :(
[05:33]  * bschaefer might have the wrong version of ibus...
[05:33] <thomi> line 73 of main.py
[05:34] <bschaefer> wow, guess Im using the wrong ibus
[05:34] <bschaefer> I cheated and just bzr branch lp:ibus
[05:35] <thomi> ummm.. I was looking at /usr/share/ibus/main.py
[05:35] <bschaefer> I usually download the source
[05:35] <bschaefer> but I don't know why I didn't think to look in the actual one being used....
[05:37] <bschaefer> hmm mines on line 217 of main.py o well
[05:50] <thomi> bschaefer: OK, I've just kicked off the build with that fix in it
[05:51] <bschaefer> thomi, did you remove my function?
[05:51] <thomi> no
[05:51] <bschaefer> because that could cause some problems
[05:51] <thomi> oh ok
[05:51] <bschaefer> yeeaah, I have it press right, enter, enter at first to activate the ibus-daemon
[05:52] <bschaefer> but for later run it messes it up and starts toggling random stuff on/off haha
[05:56] <bschaefer> cool thanks! Lets see what happens :)
[06:08] <bschaefer> ugg
[06:10] <bschaefer> thomi, https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/31/label=1EBEE0FF-DAC9-11DF-BBDA-64A98C34D485/artifact/artifacts/autopilot.tests.test_ibus.IBusTestsHangul.test_simple_input_dash%20%28document%29.ogv
[06:10] <bschaefer> well looks like it's starting to work
[06:10] <thomi> bschaefer: there's another build to come
[06:11] <bschaefer> thomi, sweet, but still  https://jenkins.qa.ubuntu.com/job/dx-autopilot-fix-ibus/31/label=1EBEE0FF-DAC9-11DF-BBDA-64A98C34D485/testReport/autopilot.tests.test_ibus/IBusTestsHangul/
[06:11] <bschaefer> looks like hangul is starting to work :)
[06:12] <thomi> cool
[06:14] <bschaefer> some pinyin test pass also :)
[06:16] <bschaefer> thomi, are you sure there is one after 31?
[06:16] <bschaefer> because it looks like 31 is the one where you removed my debug test
[06:18] <bschaefer> also half the fails are the from test_to_see_whats_happens
[06:18] <thomi> hmm, there's another one queued, maybe jenkins got confused
[06:18] <bschaefer> o
[06:18] <thomi> cool, I'll remove that test and re-push
[06:18] <bschaefer> well either way, the only test that actually fails is the anthy ones
[06:18] <bschaefer> are* no it
[06:18] <bschaefer> not*
[06:20] <thomi> ok, re-pushed
[06:21] <bschaefer> sweet :)
[06:21] <bschaefer> awesome finally some good progress :)
[06:21] <bschaefer> ugg and the problem was so simple, you were right
[06:21] <bschaefer> haha
[06:22] <thomi> well, if this fixes it I'll buy you a beer
[06:22] <bschaefer> haha awesome, you'll have to ship it to me!
[06:23] <thomi> :)
[06:23] <bschaefer> or drive 20 hours north :)
[06:23] <bschaefer> when you get to LA
[06:23] <bschaefer> ...i've driven to LA once, it was sooo long...
[06:23] <thomi> heh
[06:25] <bschaefer> but then again you're airplane rides take a while from NZ
[06:25] <bschaefer> :P
[06:48] <thomi> not as long as it was to Budapest
[06:49] <thomi> by comparison this is a short trip :)
[06:57] <bschaefer> thats good then, LA should be pretty warm around this time
[06:57] <bschaefer> Im actually starting to see the sun weekly where I live haha
[07:06] <htorque> hm, did anyone else receive ~90 mails about old nux trunk changes (revs between 488-583)?
[07:11] <didrocks> htorque: I changed the trunk right to be unversionned
[07:11] <didrocks> rather then pointing to 2.0, it's now /trunk
[07:11] <didrocks> will do the same with 2d in a few, after the release :)
[07:11] <htorque> didrocks: ah, i see.
[07:14] <bschaefer> thomi, well im off to bed, hopefully those test pass! There were for me locally, but what does that say haha
[07:15] <thomi> ok, talk to you next week I guess
[07:15] <bschaefer> o yeah it's your firday!
[07:15] <bschaefer> umm yeah Ill be on irc next week
[07:15] <bschaefer> though you guys are doing a sprint next week aren't you?
[07:16] <thomi> bschaefer: I only head out on Tuesday
[07:16] <bschaefer> o ok, cool, Ill talk with you next week then :)
[07:16] <bschaefer> have  a good weekend!
[07:17] <thomi> you too! Thanks for your help.
[07:17] <bschaefer> thomi, ugg but I really want to see if they pass
[07:17] <bschaefer> no problem! That was/possibly still has been an odd but fun bug to track down :)
[10:15] <tjaalton> hey there. I get a popup about the updates, but the window is nowhere to be seen, though the launcher and alt-tab shows it
[10:17] <seb128> tjaalton, what do you call "popup"?
[10:17] <tjaalton> seb128: the icon on the launcher saying I have updates
[10:18] <tjaalton> update-manager
[10:18] <seb128> tjaalton, what ubuntu version do you use?
[10:18] <tjaalton> seb128: guess :)
[10:18] <tjaalton> 12.04
[10:18] <seb128> tjaalton, well it could be 11.10 popping up about "do you want to update to 12.04"
[10:18] <tjaalton> it's showing 18 updates
[10:18] <seb128> tjaalton, I'm a bit surprised update-manager is already popping up by itself on 12.04, it's supposed to do that once a week
[10:18] <tjaalton> the icon
[10:18] <seb128> tjaalton, what happens if you left click on the icon?
[10:19] <tjaalton> it did so yesterday, then I killed the app from the right click menu, then on the second time it worked fine
[10:19] <tjaalton> now today it's doing the same
[10:19] <tjaalton> left-clicking does nothing
[10:19] <seb128> weird
[10:20] <seb128> will be something to ask sam about when he's around, seems like a compiz focus,stacking issue
[10:20] <seb128> I never saw it but update-manager doesn't autoopen here
[10:21] <tjaalton> it's not below any of the windows, kinda like "invisible" and inaccessible
[10:21] <seb128> tjaalton, can you open a bug with a screenshot and give the number here? I will make sure it's looked at
[10:21] <seb128> tjaalton, I had issues like that with stuff which open minimize in 11.10
[10:21] <seb128> compiz seems to not like those sometimes
[10:21] <seb128> but it's annoying if what you can't access to is your security updates
[10:22] <tjaalton> yeah
[10:23] <seb128> tjaalton, that's unity3d you use right?
[10:23] <tjaalton> seb128: yes
[10:24] <seb128> I hate when people came with those bugs the day after release rather than before ;-)
[10:24] <seb128> but shrug, not a lot we can do about it now
[10:24] <tjaalton> though.. I probably should reboot with a fresh session first, in case this was fixed after Apr 18th
[10:25] <tjaalton> well I didn't get this popup before yesterday :)
[10:30] <tjaalton> seb128: bug 989588
[10:30] <seb128> tjaalton, thanks
[12:08] <Andy80> it's just me or Empathy in Pangolin is the most bugged release ever seen :\ ?
[12:09] <Andy80> lot of time taken to connect, double clicking on a contact doesn't show anything (I had to close and reopen the client many time to make it work and it's very slow anyway), now the application doesn't show itself in the Launcher, etc...
[14:00] <Andy80> andyrock: hey :)
[14:00] <andyrock> Andy80, hey hey
[14:05] <andyrock> Andy80, what's up?
[14:08] <Andy80> andyrock: all fine, I'm stress-testing this new pangolin ;) some things to be improved (one I thing I'm going to take care of directly) and some suggestions we can talk about during UDS, but generally very nice!
[14:12] <andyrock> are you using unity 3d?
[14:15] <andyrock> Andy80, ^^^
[14:22] <Andy80> andyrock: yes, 3D, even if I'm using Nouveau driver, not Nvidia one
[14:27] <andyrock> Andy80, have you tried unity 5.12?
[14:40] <Andy80> andyrock: I don't think so... I'm just using the basic Pangolin installation. What's new?
[14:41] <Andy80> by the way... except some lens that is not working like I was expecting, the most bugs I'm finding are in the other applications (like Empathy) not in Unity itself.
[14:44] <_Pixel_> join #ubuntu-it-forum
[14:44] <_Pixel_> ops
[14:44] <_Pixel_> sorry
[14:44] <andyrock> Andy80, what's wrong the the lenses?
[14:47] <davidcalle_> Andy80, hi, if it's about the lack of sources for the video lens, it could be fixed rather easily with new scopes. What sources are you interested in?
[14:48] <Andy80> andyrock: for example I was expecting to find all video results form Youtube, but it's not like that (I also opened a bug, but it has been marked as won't fix)
[14:48] <Andy80> davidcalle_: yes, that's what I'm going to do :)
[14:48] <Andy80> davidcalle_: I'd like to improve the Youtube scope at least
[14:48] <Andy80> about 3rd party apps, Empathy is not working well... at all
[14:49] <Andy80> slow to start, I double clicked a contact and nothing happened, I had to close and reopen 3-4 times... then it's not showing in the Launcher... don't know what to think about it, I should investigate better the problems and report detailed bug reports. I'll do it.
[14:50] <davidcalle_> Andy80, there is a Youtube lens somewhere on Launchpad that could be turned, with very few changes, into a Youtube scope for the video lens. If you have any questions about scopes, just ping me or mhall119. :)
[14:53] <Andy80> davidcalle_: I first need to "study" a bit about lens and scoper, read a tutorial or something like that ;) then I'll be happy to put my hands on that code and improve it :) I've seen that it's written in Python, it will be a pleasure for me to work again with that language :)
[16:14] <KacoI4> united already?
[16:16] <Jimu> I've been hackinig around with /usr/share/unity-2d/shell/launcher/LauncherItem.qml, and it is acting weird. changing the DropItem property tileSize,defaultBackgroundColor,backgroundFromIcon doesn't have any effect, but if I change the values of item.tileSize etc, it has an effect. is there somewhere else I can find this behavior's code?
[16:36] <rajmahendra> I have upgraded my Ubuntu to 12.4 today i shoutdown and restarted my laptop after i login to my accoutn i see that Unity is not showing the launcher nor i can get the dash. i switched to Gnome. can anyone help me in this to enable unity on my account ?
[16:37] <rajmahendra> Anyone guide me ?
[16:42] <rajmahendra> anyone here to help ?
[16:44] <Jimu> rajmahendra: you just upgraded and didn't change anything afterwards?
[16:51] <rajmahendra> yes
[16:51] <rajmahendra> i upgraded and restarted
[16:51] <rajmahendra> unity in my account is not displaying dash or launcher
[16:51] <rajmahendra> alt is not workign windows button is nto wroking.
[16:56] <rajmahendra> jimu: any restart or anything i need to add
[16:57] <Jimu> rajmahendra: had you made alterations to your Unity before the upgrade? Have you tried logging in with Unity2D?
[17:53] <tgm4883> In the videos lens/scope (or I suppose others may work as well), is there a way to detect exiting of video playback?
[19:27] <Andy80> hey guys, just a little note... why all the "Ubuntu Countdown" banners are still showing "Coming Soon" ?


[00:00] <nacc> rbasak: iirc, it didn't work the way it seems like it should
[00:00] <nacc> rbasak: let me see if i have notes
[00:01] <rbasak> We'd need to drop the extracted_dir os.listdir search thing too. Maybe hardcode it to "$extract_dir/x" or similar.
[00:01] <nacc> right, but like i said, i think that's what i had before and it didn't do what you expected
[00:01] <nacc> :)
[00:02] <nacc> rbasak: ah, it's because the output directory must not already exist
[00:02] <nacc> and there's no way to make it a temp directory then, without our own managment
[00:03] <rbasak> That's what I meant by "$extract_dir/x".
[00:03] <nacc> rbasak: i guess we could racily do a tempname() or whatever, but then... racy
[00:03] <rbasak> Let me show you what I mean.
[00:04] <nacc> rbasak: ok
[00:07] <rbasak> nacc: roughly rewritten dsc_to_tree_hash: http://paste.ubuntu.com/23784442/ (untested, diff not helpful)
[00:09] <nacc> rbasak: won't, line 59 create the temp directory?
[00:09] <nacc> rbasak: per `man dpkg-source` the output dir cannot already exist
[00:09] <nacc> that's what i was trying to say above
[00:09] <rbasak> nacc: 59 will create temp_dir, yes. But dpkg-source will run on $temp_dir/x, not $temp_dir.
[00:10] <nacc> rbasak: oh i see what you're doing
[00:10] <rbasak> So then I don't have to search to find out what it called it, and I get to use $temp_dir for $temp_dir/index later on as well.
[00:10] <nacc> if you can test it, then sure, that's fine
[00:10] <nacc> it seems reasonable, i mean
[00:10] <rbasak> OK, thanks. I'll clean up and rebase.
[00:10] <nacc> i'd like a comment or something, maybe? it's basically a sneaky way to workaround dpkg-source behavior
[00:11] <nacc> and easy to miss, imo :)
[00:11] <rbasak> Sure
[00:11] <nacc> rbasak: otherwise, in general, the changes for unapproved look good
[00:11] <nacc> rbasak: how hard was it for you to spin up the changes? just wondering how non-pythonic i'm being
[00:13] <rbasak> nacc: your code is pretty nice and Pythonic IMHO. The only pain was in shoring up some leaky abstractions, but I think that's to be expected. The number of times the code has been adjusted, and not knowing where we were going in the first place meant that it was inevitable. And I think it's fine to clean up as we go along, so anything I touch I'm cleaning up.
[00:14] <rbasak> nacc: maybe a few missing context managers (cleaning up stuff by hand instead of using "with" blocks). But nothing major.
[00:15] <nacc> rbasak: yeah i think i didn't/don't know enough about the pythonic way at the start, so it's probably more imperative and LBYL than it should be. I've been cleaning that up as I go as well
[00:16] <rbasak> As we're talking about it:
[00:16] <rbasak>             raise SourceExtractionException
[00:16] <rbasak> That raises the class object. Should be SourceExtractionException() really - an instance of an exception rather than the definition of one itself.
[00:16] <nacc> ah of course, makes sense
[00:17] <rbasak> But this stuff is minor really. Doesn't matter much!
[00:17] <rbasak> I intend to extend the unapproved stuff and call it "queue" BTW. Since I realised today I want NEW handling too.
[00:18] <rbasak> Since in SRUs, stuff that hits NEW is often backported from the dev release, and I want to diff against those and they can be imported.
[00:18] <nacc> rbasak: yep, makes sense to me
[00:18] <nacc> rbasak: would 'unapproved' be a flag to queue then for that specific case?
[00:19] <rbasak> My plan is that "usd queue" will update all queue/{new,unapproved}/<release> tags as necessary.
[00:20] <nacc> ah ok
[00:20] <rbasak> Assuming you run that from something you have already done "usd clone" on.
[00:20] <nacc> right, this is all 'detached' from the usd side, right? local-only, i mean?
[00:20] <rbasak> One catch is that I need some way to know what package name to operate on. I'm not sure we store that currently. So I might ask for that to be added with "git config" at "usd clone" time or something.
[00:20] <nacc> usd git side, i meant
[00:20] <rbasak> Correct. All local only.
[00:21] <nacc> yeah, it's probably not a bad idea to stuff that somewhere
[00:21] <rbasak> Then, later, I might add something that pulls the entire queue for a release, or all stable releases, or all releases, clones them all, makes sure they're all up-to-date (rerunning "usd import") and then runs "usd queue" in all.
[00:22] <rbasak> Also perhaps "usd queue approve" or something to accept from the queue a given tag.
[00:22] <rbasak> As I'm storing the Launchpad queue object API URI in the tag, that should be reliable.
[00:23] <nacc> ah ok
[00:23] <rbasak> (or reject)
[00:23] <rbasak> I need to think about the CLI a little.
[00:23] <nacc> yeah that seems tricky
[00:23] <nacc> we can always mark that part as 'alpha' :)
[00:23] <rbasak> It's only a small set of people who can usefully use it, so I think that's feasible :)
[00:24] <nacc> and, presuming deps are installed, tab complete works now, so maybe that will help with the options too
[00:24] <rbasak> I saw that commit. Neat!
[00:27] <nacc> it's a bit slow, which i think is because of my ordering decisions, which can be fixed
[00:28] <nacc> but it does work, so little steps :)
[00:43] <rbasak> nacc: I've updated my branch (fast-forward) so it works but will rebase and squash later to tidy it up.
[00:45] <nacc> rbasak: ack, just ping me when you're ready for me to merge it in (even if just hte cleanup stack)
[00:45] <rbasak> Will do
[00:48] <nacc> rbasak: thanks!
[00:53] <nacc> rbasak: ah, so nice to remerge something i've merged before, it's already broken up (so `git fetch lpusip; usd merge lpusip/ubuntu/devel lpusip/debian/sid; git rebase -i [to drop the empty merge commits]`, puts me at a fully deconsructed state already
[11:35] <Mirv> mitya57: retrying pyqt5 i386 as lack of it is blocking Qt 5.7.1 transition and it seems qtwebengine is however now built for i386
[11:40] <Mirv> mitya57: nope, still failed with "Depends: qtwebengine5-dev (>= 5.7.1+dfsg-3~) but it is not going to be installed", maybe it's unistallable for some reason
[11:58] <Mirv> mitya57: ah, pyqt5 amd64 binaries are in new queue
[12:23] <tsdgeos> Mirv: what's holding Qt 5.7.1 landing?
[12:23] <tsdgeos> i see it marked as "Valid candidate" in the excuses page
[12:26] <Mirv> tsdgeos: did you read the lines below which you wrote? :)
[12:26] <tsdgeos> reading which kind of crazyness is this?
[12:27] <tsdgeos> i see, tx
[13:04] <acheronuk> Mirv: i386 still did not build, or did you prod it too soon for the amd64 indep packages to have published and be available?
[13:15] <acheronuk> E: Package 'libqt5webengine-data' has no installation candidate
[13:15] <acheronuk> so I guess needs to wait a bit
[13:28] <rbasak> pdeee: can you tell me the relationship between the python-letsencrypt, python-acme and python-certbot source packages please? Which replaced which?
[13:30] <rbasak> Is it that acme remains unchanged as the backend protocol library, and letsencrypt->certbot?
[13:33] <rbasak> pdeee: I don't understand why I don't see a python-letsencrypt transitional package in src:python-certbot in the Xenial new queue.
[13:34] <rbasak> Only one for letsencrypt with no prefix.
[13:45] <rbasak> pdeee: I commented in the bug.
[14:05] <LocutusOfBorg> slangasek, FYI I syncd "libdfp"
[14:08] <Mirv> acheronuk: seems like that, now it's building
[14:09] <acheronuk> Mirv: so is my staging ppa stuff that was waiting on it :)
[14:36] <pete-woods> xnox: hi. just looking back at your change in indicator-network at this revision: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk/revision/660
[14:36] <pete-woods> in the maintscript you do etc/.../ instead of /etc/.../
[14:36] <pete-woods> i.e. without the leading /
[14:36] <pete-woods> is that intentional, or a mistake?
[14:37] <pete-woods> cause it looks like the scripts are not successfully removing the old XDG files
[14:38] <pete-woods> just wanted to double-check before I blunder in and naïvely stuff a / in
[14:39] <cjwatson> looks like a clear mistake to me.  lots of debhelper files don't need the leading / (and it's conventional to avoid it since the paths are really relative to the installation hierarchy), but .maintscript is just passed through to dpkg-maintscript-helper which does need the leading /.
[14:41] <pete-woods> cjwatson: thanks for having a look :) - will put a MR together to fix it, then
[14:41] <cjwatson> also IMO that should have a version in it somewhere
[14:41] <xnox> pete-woods, mistake.
[14:41] <pete-woods> Removing obsolete conffile /etc/xdg/autostart/indicator-network.desktop ...
[14:41] <pete-woods> woot, looks like it's behaving again now
[14:41] <xnox> pete-woods, but fixed seperately
[14:41] <xnox> pete-woods, https://launchpad.net/ubuntu/+source/indicator-network/0.9.0+17.04.20161223.3-0ubuntu2
[14:42] <xnox> i think that needs remerging, and relanding.
[14:42] <xnox> cjwatson, there should be a version, but i did not know how to do it properly with substitution of magic version numbers in the silo.
[14:42] <cjwatson> doesn't have to be a version that exists, as long as it's comparable :-)
[14:42] <pete-woods> oh, did you land that without going through CI train?
[14:43] <cjwatson> (also I think bileto supports some kind of poorly-named hack along the lines of 0replaceme
[14:43] <cjwatson> )
[14:43] <pete-woods> anyway
[14:43] <pete-woods> will try and make the same change again
[14:48] <pete-woods> cjwatson: would 0.9.0+17.04.20161223.3-0ubuntu1~ work as the version to compare?
[14:48] <pete-woods> (that's the revision that the conf file was removed from)
[14:48] <pete-woods> there are so many special characters in the bileto versions, I don't know what is greater or less than anything else
[14:48] <xnox> pete-woods, it should be the version that successfully removes it so 0.9.0+17.04.20161223.3-0ubuntu2~ and whatever new for xenial.
[14:49] <xnox> i'll try to find the docs for the replaceme stuff.
[14:49] <pete-woods> xnox: so I need to know the replaceme thing then, okay
[14:49] <pete-woods> also, a link to those docs would be great
[14:49] <pete-woods> I don't see, e.g. 0replaceme, in https://wiki.ubuntu.com/Bileto
[14:51] <dobey> grrrr
[14:52] <dobey> pete-woods: well apparently now you have to manually merge the changes from zesty, and then do a no change rebuild
[14:52] <pete-woods> dobey: indeed. always a bit annoying when this happens
[14:52] <dobey> or change the version in the maintscript to be @replaceme
[14:53] <pete-woods> dobey: i'm happy enough with 0replaceme, if I can find the correct string
[14:53] <cjwatson> pete-woods: use dpkg --compare-versions to test things out
[14:54] <cjwatson> (badly-named> the design basically assumes there's only ever one thing that might want to be replaced, and it isn't self-documenting)
[14:55] <cjwatson> pete-woods: https://wiki.ubuntu.com/DailyRelease/FAQ documents 0replaceme
[14:55] <dobey> pete-woods: it's "0replaceme"
[14:55] <cjwatson> albeit in stuff about symbols files, but same idea
[14:55] <dobey>  (c++)"UbuntuOne::Token::addOAuthTimestamp(QString) const@Base" 0replaceme
[14:55] <cjwatson> in this case it should be 0replaceme~ though, I think
[14:55] <dobey> from a previous branch i landed
[14:56] <dobey> cjwatson: maybe, but i think the ~ might break it?
[14:56] <cjwatson> break it how?
[14:56] <dobey> 0replaceme~ != 0replaceme
[14:56] <cjwatson> scripts/vcs.sh:    find debian/ -type f -print0 | xargs -0 perl -p -i -e "s/0replaceme/$VERSION/g"
[14:56] <dobey> oh ok
[14:56] <cjwatson> so I shouldn't think so
[14:57] <dobey> yeah if the regex is that dumb it's fine. i just didn't know how clever it was trying to be :)
[14:57] <dobey> pete-woods: ^^ so 0replaceme~ is what you want in the maintscript for the version
[14:58] <pete-woods> Cool, will stuff that in
[15:49] <LocutusOfBorg> hello, how do I fix this bug? https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/1557675
[15:49] <LocutusOfBorg> sorry https://bugs.launchpad.net/ubuntu/+source/hedgewars/+bug/1649660
[15:49] <LocutusOfBorg> this one
[15:53] <Laney> LocutusOfBorg: http://appstream.ubuntu.com/zesty/universe/issues/hedgewars.html
[15:53] <Laney> same @ debian
[15:53] <LocutusOfBorg> thanks
[15:54] <LocutusOfBorg> so no icon is missing
[15:54] <LocutusOfBorg> wonderful
[15:55] <LocutusOfBorg> so adding a Comment section is enough
[16:03] <LocutusOfBorg> ta!
[16:09] <caribou> infinity: I had a question about silently changing a conffile for tftpd-hpa on Trusty
[16:09] <caribou> infinity: that's a discussion we had with rbasak recently
[16:10] <infinity> caribou: What's the question, and can I answer it with "don't do that"?
[16:10] <caribou> infinity: right now, tftpd-hpa will fail to start if the NIC is not available because it is listening on [::]:69
[16:10] <caribou> infinity: the fix is to change it to :69 in the conffile. rbasak had worries about that triggering a conffile prompt upon update
[16:11] <infinity> Oh.  Triggering a conffile prompt because a conffile was updated is exactly why the prompts exist.
[16:11] <caribou> infinity: and thought that we might sed it in the postinst, since :69 encompass the [::]:69 value and will work in every situation
[16:11] <infinity> No.  Changing it in postinst is wrong.
[16:11] <caribou> infinity: I know, but it seemed to bother rbasak
[16:12] <caribou> rbasak: got a comment on this ?
[16:12] <rbasak> I said preinst, but I also decided that may not work.
[16:12] <caribou> rbasak: yes, sorry preinst
[16:12] <rbasak> I wondered if there was some way to work around a conffile prompt since the two are exactly equivalent, so we may be able to sed in all cases.
[16:12] <rbasak> But I'm not sure there is.
[16:12] <rbasak> Anyway. Someone wants a conffile change? Automatic referral to infinity :-P
[16:13] <infinity> Changing it in preinst is also wrong. :)
[16:13] <ogra_> nah, just to a boit that says "don't do that !"
[16:13] <ogra_> *bot
[16:13] <infinity> If they've customized their config, we assume they like the one they have, hence the prompt.
[16:14] <infinity> If they haven't touched it, they get the new one silently.
[16:14] <ogra_> unless an insane developer mangled it from a maintainer script before :)
[16:14] <infinity> The default may be "bad", but we have to assume that if they've touched the file, they audited and decided they liked the bad default.
[16:15] <infinity> ogra_: And that developer will be flogged later.
[16:15] <ogra_> :D
[16:16] <caribou> rbasak: infinity: I had a similar query regarding a conffile mod for a makedumpfile SRU
[16:16] <caribou> rbasak: infinity: I'm doing an SRU of a fix in Zesty that brought in two new values to a conffile. Those values are not required to be present in the conffile and can be added later to alter some timings. Would it be sufficient to add a mention in the README to avoid a conffile prompt ?
[16:16] <infinity> Now, that said, I don't see a conffile in tftpd-hpa...
[16:16] <LocutusOfBorg> Laney, how long will it take to regenerate that info on software catalog once hedgewars is uploaded?
[16:16] <Laney> LocutusOfBorg: Not long, few hours at most
[16:17] <LocutusOfBorg> ok I uploaded it a few seconds ago
[16:17] <LocutusOfBorg> so, do I need to apt update  or is something automatic?
[16:17] <infinity> rbasak, caribou: /etc/default/tftpd-hpa is *not* a dpkg conffile, it's created by postinst.
[16:18] <rbasak> Oh
[16:18] <infinity> rbasak, caribou: And that throws all your concerns about dpkg conffile prompts out the window.  It's managed by debconf.
[16:18] <rbasak> caribou: sorry!
[16:18] <caribou> infinity: sorry!
[16:18] <caribou> :)
[16:18] <ogra_> heh
[16:19] <Laney> LocutusOfBorg: Did you run desktop-file-validate?
[16:19] <Laney> I think that you made a syntax error
[16:19] <rbasak> Well then we can just sed it. Though policy does still require that we preserve user changes.
[16:19] <infinity> Well, "managed".  It seems to be a broken setup that doesn't allow debconf to reconfigure. :P
[16:19] <rbasak> And do we also need to manipulate the debconf db?
[16:19] <LocutusOfBorg> Laney, I did run it
[16:19] <caribou> rbasak: the sed would only change it if it was set to the previous default ([::]:69]
[16:20] <infinity> rbasak: debconf is not a registry, you should never need to touch the db.
[16:20] <caribou> ([::]:69)
[16:20] <Laney> LocutusOfBorg: share/hedgewars/Data/misc/hedgewars.desktop: error: file contains line "Comment: Funny turn-based artillery game, featuring fighting hedgehogs!", which is not a comment, a group or an entry
[16:20] <infinity> rbasak: If maintainer scripts aren't written to prefer the config file over the DB, that's a bug.
[16:20] <LocutusOfBorg> DAMN
[16:20] <LocutusOfBorg> you are right
[16:20] <LocutusOfBorg> I didn't quilt push
[16:20] <rbasak> infinity: what if debconf suggested the previous default to the user, and then stored it?
[16:20] <LocutusOfBorg> :/
[16:20] <LocutusOfBorg> dpkg-buildpackage unapplies patches
[16:20] <rbasak> rbasak: then a future dpkg-reconfigure would restore the old default, no?
[16:20] <infinity> rbasak: See above.  The authoritative version is always the config file, never the debconf DB, per policy.
[16:21] <rbasak> Ah, so the config script should read the config file over the DB when prompting for future defaults? That makes sense, thanks.
[16:21] <LocutusOfBorg> ta
[16:21] <infinity> rbasak: And, indeed, the tftpd-hpa package does that correctly (sources the config file, stores the values, then asks questions).
[16:21] <cjwatson> picking the current state out of the config file and stuffing it into debconf as the default value before asking a question is OK though
[16:21] <cjwatson> yeah, that
[16:21] <infinity> rbasak: What I don't see it doing is actually rewriting the config file on reconfigure. :)
[16:22] <infinity> But hey, minor oops.
[16:22] <Laney> LocutusOfBorg: Might want to cancel the builds to save the environment a bit. :)
[16:23] <LocutusOfBorg> indeed
[16:24] <infinity> caribou: As to your makedumpfile thing, you can either ship a new conffile with the new keys or not.  Your call as the maintainer.
[16:25] <infinity> caribou: If it behave correctly without the keys specified, mentions of them in changelog, READMEs, or manpages are all fine.  *shrug*
[16:25] <caribou> infinity: the new keys are only comments for reference
[16:25] <caribou> infinity: k, I started to have second thoughts after rbasak's comments about tftpd-hpa
[16:25] <infinity> caribou: To be fair, people will see that conffile prompt on 16.04->18.04 upgrades anyway, so you can't avoid it forever.
[16:26] <infinity> caribou: (Well, they'll see it if they changed their local copy)
[16:26] <infinity> conffile prompts aren't evil, what's evil is when packages alter conffiles outside the proper dpkg mechanism and create *spurious* prompts.
[16:27] <infinity> Users being prompted because *they* changes the file and then you shipped a new one is working as designed.
[16:27] <infinity> s/changes/changed/
[16:27] <caribou> infinity: yeah,never worried too much about it as I saw it as expected behavior
[16:28] <rbasak> One problem though is that some people never see conffile prompts (unattended upgrades, etc). So then default conffile handling behaviour takes over, which I think may be confold? And then that defeats some of the point of fixing it, if the goal is to get those users as well.
[16:28] <rbasak> This applies to server stuff quite a bit, where a commonly conffiles have to be edited for their packages to be useful.
[16:29] <infinity> Default should be confold, yeah.  I'd like to think people who run unattended-upgrades on critical infrastructure also go looking for .dpkg-new in /etc occasionally.
[16:29] <infinity> But I bet they don't.
[16:29] <infinity> I wonder if we could motd snippet that or something.
[16:29] <cjwatson> I've gone through all the stages of grief on this and eventually decided that conffile prompts (or ucf) are still the least painful thing.
[16:29] <infinity> "A recent upgrade resulted in N unmerged conffiles in /etc"
[16:29] <rbasak> That's a good idea.
[16:30] <cjwatson> After having years of accretion of weird sshd_config editing runes in openssh-server.postinst.
[16:30] <cjwatson> infinity: Very Gentoo :-)
[16:30] <caribou> yeah, I like the fact of being told about things that should be looked at
[16:30] <cjwatson> (It has something very similar IIRC)
[16:30] <infinity> cjwatson: Oh, I thought you were punning about emerge.
[16:31] <infinity> cjwatson: But yeah, if they have something like this, they might be doing something right.  rbasak's not wrong that there's a general conflict between silent upgrades and conffile updates.  Post-facto notification seems not entirely bad.
[16:31] <cjwatson> Gentoo doesn't have any automatic conffile merging, so it *has* to have a prompt at the end to tell you to apply changes.  But that's not to say it's a bad idea.
[16:36] <infinity> I wish we'd done etckeeper-by-defalt long ago, so we could just say "/etc has unresolved conflicts, fix plz".
[16:37] <infinity> Well, and hook it into dpkg, so a conffile update is actually a merge attempt that vomits to conffile.rej on failure, etc.
[16:37] <infinity> Woulda shoulda coulda.
[16:38] <infinity> I suppose we still could some day.
[16:40] <infinity> Though, I guess working toward the new world oder of "defaults in /usr, overrides in /etc" is a better use of time.
[16:40] <infinity> Maybe we can actually have an empty /etc by 2038.
[16:42] <infinity> Well, empty except for /etc/rmt, because that bit of backward compatibility is super important to someone from 1972.
[17:22] <philroche> Hi guys, I'm hoping someone can steer me in the right direction. Earlier today gce-compute-image-packages was accepted in to xenial-proposed pocket but the binaries are not being published to the repository. The amd64 build is stuck "Pending publication" (See https://launchpad.net/ubuntu/+source/gce-compute-image-packages) Is there anything I need to do to get past that stage or is it just a matter of waiting?
[17:27] <nacc> philroche: i'm guessing here, but it's a new src and binary, so it will need approval by an AA to migrate to -proposed.
[17:28] <seb128> could somebody from the SRU team copy https://launchpad.net/ubuntu/+source/evolution/<IP_ADDRESS>-0ubuntu3.1 over from xenial-proposed to updates? the update was accepted without a bug reference and is probably stucked because of that but the change is fine and has been tested
[17:28] <seb128> bdmurray, ^ you maybe?
[17:29] <bdmurray> seb128: looking
[17:29] <seb128> bdmurray, thanks
[17:29] <cjwatson> nacc is correct; the binaries are new in that suite so it's in the NEW queue for approval.
[17:29] <nacc> philroche: --^
[17:31] <bdmurray> seb128: released it
[17:31] <philroche> cjwatson: nacc: Thanks
[17:31] <seb128> bdmurray, thanks!
[17:34] <nacc> philroche: note that you can also see that from https://launchpad.net/ubuntu/+source/gce-compute-image-packages/20160930-0ubuntu3~16.04.0 (the '(New)') next to the build
[17:34] <philroche> nacc: Ah. I see thanks
[17:35] <nacc> philroche: and you can also see it here: https://launchpad.net/ubuntu/xenial/+queue
[17:45] <philroche> nacc: This process is new to me so thanks for that.
[17:46] <nacc> philroche: np, I often forget about it too :)
[17:46] <nacc> philroche: / it's new to me as well
[17:48] <sil2100> Laney: hey! Would you mind if I re-upload the dbus package with just the ssh/logind workaround?
[17:49] <Laney> sil2100: If you take over the other fix too
[17:50] <sil2100> Laney: what do you mean?
[17:50] <sil2100> Laney: I see it's marked as verification-failed right now and causing some issues, right?
[17:50] <sil2100> We just want to get the ssh fix released as soon as possible as many users are waiting for it
[17:52] <Laney> sil2100: Yes, but it's not buggy itself. If you want to revert it to get your other fix in, then I would appreciate you taking care of putting it back when it is safe to do so.
[17:52] <sil2100> Laney: ah, like this
[17:52] <sil2100> Ok
[17:53] <sil2100> Laney: I can do that sure
[17:53] <Laney> Cheers
[18:01] <nacc> rbasak: still around?
[18:11] <mitya57> Mirv, it looks like pyqt5 built everywhere now.
[18:46] <Mirv> mitya57: yes. if you or someone has time, look at the qtquickcontrols examples installability issue on excuses page (I'm going to sleep now already)
[18:47] <Mirv> qtquickcontrols5-examples/amd64 unsatisfiable Depends: qml-module-qtquick-extras etc
[18:48] <Mirv> acheronuk: ^ note, at least that found from excuses page, no need yet to decipher update_output more
[18:50] <bdmurray> Laney: Do you know what Code 20 means in autopkgtest results?
[18:53] <davmor2> bdmurray: it's a countdown to total global annihilation you really need to stop it before it gets to 0 ;)
[18:53] <mitya57> Mirv, qtquickcontrols5-examples is installable in my amd64 chroot.
[18:55] <mitya57> Though, qml-module-qtquick-extras is the only dependency that is in universe, so probably that is the issue.
[18:57] <mitya57> Maybe someone can promote it to main? (It comes from qtquickcontrols-opensource-src source which is in main.)
[19:00] <pdeee> rbasak, hlieberman and RAOF may be better equipped to answer your questions, but
[19:01] <pdeee> AFAICT python-certbot Replaces: python-letsencrypt
[19:03] <pdeee> python-acme is a dependency of either of those
[19:03] <pdeee> not sure how that relates to source packages, though
[20:20] <bdmurray> jbicha: How was bug 1649995 fixed in zesty? Just setting it to Fix Released doesn't help me from an SRU perspective.
[20:29] <bdmurray> zul: The existing nova-lxd SRU hasn't been verified (bug 1642274). Do you want the new upload to supersede it?
[20:30] <zul> bdmurray: lemme check around
[20:30] <bdmurray> zul: okay
[20:36] <smoser> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html <-- why is cloud-initramfs-tools there ?
[20:36] <smoser> 'missing build' seems relevant, but there is a build
[20:37] <hlieberman> rbasak: Hiya.  Debian maintainer of the certbot stuff here.
[20:37] <hlieberman> rbasak: So, yes, you're correct: python-acme stays the same, python-letsencrypt => python-certbot, letsencrypt => certbot, python-letsencrypt-apache => python-certbot-apache
[20:38] <hlieberman> Generally, users wouldn't have installed python-letsencrypt directly, so there's no transitional package there.
[20:41] <cjwatson> mitya57: done
[20:45] <hlieberman> If they did, they could be using plugins that wouldn't work in the new namespace.
[20:48] <jbicha> bdmurray: it was fixed in gnome-online-acccounts 3.22.3-1, I've added that to Other Info on the bug now
[20:49] <jbicha> we have to figure out how to get evolution through phased-updates though…
[20:52] <bdmurray> jbicha: Do you know anything about this new crash?
[20:54] <jbicha> no, it does look new; I can ping the evolution maintainers about it
[20:57] <jbicha> actually it was evolution-data-server that needed to be updated first but that's fully phased so we don't need to let that stop us from updating g-o-a now
[20:58] <bdmurray> looking at the error tracker I don't see any other crashes with webkit_editor
[21:01] <jbicha> right and it was in yakkety that evolution switched from webkit1 to webkit2 so it's probably new to yakkety
[21:21] <jbicha> bdmurray: thanks. Could you look into the libicns yakkety SRU? it's needed for hdhomerun-config-gui to build there
[21:46] <nacc> juliank: do you know what's going on with LP: #1522675? seen an uptick lately in people hitting it on #ubuntu
[21:47] <juliank> nacc: More users upgrading to >= xenial?
[21:48] <juliank> Someone may want to play with update-notifier's use of apt-helper and have it download stuff into a directory writeable by the _apt user
[21:49] <nacc> juliank: checking on the current user who brought it up
[21:51] <juliank> Same for synaptic apparently.
[21:51] <juliank> Funny how ubottu  says bug in update-notifier (Ubuntu)  but the link it gives redirects to https://bugs.launchpad.net/debian/+source/synaptic/+bug/1522675
[21:52] <nacc> juliank: in this case, user already ahd fonts package installed, and a regular update failed, it seems (on 16.04). Not dist-upgrading.
[21:52] <nacc> juliank: multiple tasks in same bug
[21:52] <juliank> Well, nothing is failing there
[21:52] <nacc> juliank: can be referred to by multiple src pkgs (therefore)
[21:53] <juliank> nacc: I think you really meant bug 1651923
[21:54] <nacc> juliank: ah that's the underlying spaces issue?
[21:55] <juliank> There's a workaround in zesty, and I'll backport this shortly to yakkety and xenial, but I first want to write a regression test case and optimally do the whole thing in an upstream release (scheduled in 4-5 days)
[21:55] <nacc> juliank: ack, just trying to get context so I can provide the best answer(s) in #ubuntu
[21:55] <nacc> juliank: right now, folks are manually installing the .deb from unstable
[21:55] <nacc> for the fonts package
[21:56] <juliank> That works too as it skips the redirector or something
[21:57] <nacc> yeah, i think the fonts package (debian) has changed that as well
[21:57] <nacc> so it's like there are two fixes :) (for that particular package)
[21:57] <juliank> Yeah, but there's others mentioned in the bug log
[21:57] <nacc> yep, presumably any of the ones that are downloading something during the install could be affected
[21:57] <jbicha> I'm guessing bug 1607535 is the same issue
[21:57] <nacc> juliank: thanks for the bug link and clarification!
[21:58] <nacc> jbicha: ack, that's the one i saw yesterday
[21:58] <juliank> If anyone is an http expert: I only urlencoded the path component of URLs we give to curl. I wonder if I should also urlencode some more parts - but I'm not sure.
[21:58] <nacc> jbicha: dunno if you want to update with references to the other two bugs
[21:58] <jbicha> if 1651923 is the main bug, we can duplicate the other bugs to there
[21:59] <juliank> jbicha: Keep one open for the package update request?
[21:59] <juliank> It's the same underlying issue of course, but a package update obviously also entails other things and is good to have in either case.
[22:00] <jbicha> oh for ttf-mscorefonts? I'll open a different bug requesting that be updated
[22:01] <juliank> Yes. I remember someone tried merging that yesterday, but it was a bit complicated.
[22:33] <rbasak> hlieberman: hi
[22:33] <rbasak> hlieberman: still, it makes python-letsencrypt un-updateable, so I think we do need an update for it bundled with this SRU.
[22:34] <hlieberman> rbasak: A dummy?
[22:34] <rbasak> hlieberman: we could drop letsencrypt from src:python-letsencrypt, and the same for apache if that works the same way.
[22:34] <rbasak> hlieberman: since src:python-certbot is taking the package over.
[22:35] <hlieberman> src: python-letsencrypt can be RMed.
[22:35] <hlieberman> It's completely replaced.
[22:35] <rbasak> hlieberman: not from a stable release, unfortunately.
[22:36] <rbasak> We could replace it with an empty package, but users may still theoretically be using python-letsencrypt ("import letsencrypt"), and I don't think there's any need to drop that from a stable release here.
[22:36] <hlieberman> python-certbot Break's python-letsencrypt.
[22:36] <rbasak> Oh.
[22:36] <rbasak> Well, that's something that should be discussed in the bug then.
[22:37] <rbasak> Because it's a use case that could exist that we definitely are breaking.
[22:37] <hlieberman> Because it ships a symlink for /usr/bin/letsencrypt and Provides: letsencrypt.
[22:37] <rbasak> Surely that's letsencrypt, not python-letsencrypt?
[22:37] <rbasak> Uh, sorry.
[22:37] <rbasak> Surely that's certbot, not python-certbot?
[22:38] <hlieberman> Oh, yeah. Sure. I suppose someone could theoretically want python-letsencrypt but not letsencrypt, though it would be very strange.
[22:38] <rbasak> Why aren't they the same package?
[22:39] <hlieberman> The library isn't really meant to stand alone, like python-acme is.
[22:39] <hlieberman> They're the same source package.
[22:39] <rbasak> Why aren't they the same binary package?
[22:40] <hlieberman> Sorry; I'm on my cell phone, so I might not be explaining this very well.
[22:40] <rbasak> If it's not meant to stand alone, shouldn't it be in /usr/lib/certbot?
[22:40] <rbasak> https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs "4.2.1 Programs Shipping Private Modules
[22:40] <rbasak> "
[22:41] <hlieberman> It's can't be private in that sense, since a third package does depend on it. python-certbot-apache.
[22:41] <rbasak> I see, OK.
[22:42] <rbasak> Why must python-certbot Breaks: python-letsencrypt?
[22:42] <hlieberman> And python-certbot-nginx, though that's not relevant.
[22:42] <rbasak> AFAICT, they provide different files.
[22:42] <hlieberman> It doesn't. I'm sorry, I meant s/python-// before.
[22:42] <hlieberman> That's my fault.
[22:43] <hlieberman> certbot breaks letsencrypt.
[22:43] <rbasak> Actually it looks like it does.
[22:43] <rbasak> In queue/xenial/new
[22:43] <rbasak> Package: python-certbot
[22:43] <rbasak> Breaks:...python-letsencrypt (<= 0.6.0)
[22:44] <rbasak> Replaces: python-letsencrypt
[22:44] <hlieberman> Ah -- are you going to be around in a bit? This really should wait until I'm actually in front of my computer.
[22:44] <rbasak> I appreciate that's fine for ongoing development.
[22:44] <rbasak> But for the SRU, maybe we could drop that?
[22:44] <rbasak> I'll be going to bed soon, sorry. We can chat another time though, just ping me.
[22:44] <hlieberman> Since I am clearly not word-ing very well.
[22:44] <hlieberman> Sure thing. I'll put something in the bug and try and catch you tomorrow.
[22:45] <rbasak> OK. I appreciate you getting in touch. Thank you for helping with this.
[22:45] <hlieberman> Of course! Sorry for the confusion
[22:45] <rbasak> No problem. It's confusing by its nature. I don't mind working through it, just want to get to the bottom of it and reach an agreement and get it done :)
[22:48] <hlieberman> Yeah. The differences between Debian and Ubuntu is just slight enough to really trip me up, too.
[22:49] <hlieberman> Like with Maintainer. I know I knew that, once upon a time.


[09:35] <tumbleweed> mdeslaur: sorry, we don't have enough disk space on ubuntuwire for reverse-depends of ESM, at the moment
[09:35] <tumbleweed> when we get some more space, then I can enable it
[10:22] <mdeslaur> tumbleweed: wow, ok, thanks
[10:23] <tumbleweed> it's not much, but we're close to the limit atm
[10:24] <mdeslaur> sure, I understand


[05:25] <Unit193> http://arstechnica.com/tech-policy/2015/07/kentucky-man-shoots-down-drone-hovering-over-his-backyard/ problem?  Nope.
[10:14] <wrst> Ha ha


[00:38] <lifeless> fun - OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
[00:38] <lifeless> Unable to establish SSL connection.
[00:39] <rick_h_> wallyworld__: so just an fyi along the lines of what I was thinking. https://pastebin.canonical.com/75528/ is where I'd head to try to make sure the privacy.js is decoupled from the information_type.js aside from listening to the event.
[00:40] <lifeless> erm wtf
[00:40] <lifeless> telnet> open <IP_ADDRESS> 443
[00:40] <lifeless> Trying <IP_ADDRESS>...
[00:40] <lifeless> Connected to <IP_ADDRESS>.
[00:40] <lifeless> Escape character is '^]'.
[00:40] <lifeless> HELO
[00:40] <lifeless> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

501 Method Not Implemented</title>
[00:40] <lifeless> :)
[00:41] <wallyworld__> rick_h_: looks ok at first glance. the get_banner_text function can probably be taken off the namespace now with these changes
[00:41] <lifeless> right, thats better.
[00:41] <rick_h_> wallyworld__: right, not complete
[00:42] <rick_h_> wallyworld__: but I wanted to kind of clear up the idea/where I'm trying to head to make sense of it more
[00:42] <lifeless> whoever had that apache not working to lp.dev before, if you're using lxc etc, make sure your apache config is listening on *:443, not <IP_ADDRESS>:443
[00:43] <wgrant> lifeless: I added a feature to Makefile to do that, which I added to the LP LXC docs
[00:43] <wallyworld__> rick_h_: looks ok so far but i probably need to get into the code a little more. i'd run your changes by jc since he did some banner work a few months ago
[00:43] <lifeless> wgrant: I was giving the lp-setup inline docs a spin
[00:44] <lifeless> wgrant: they are incomplete
[00:44] <rick_h_> wallyworld__: yea, honestly I'm afk for a week so I'd not worry about it too much. Just hoping to make me seem les insane
[00:44] <lifeless> (because it goes for test-suite capability)
[00:44] <wallyworld__> rick_h_: np. it's all good
[00:44]  * rick_h_ swears he's not lost it yet
[00:51] <wgrant> lifeless: Right
[01:14] <lifeless> how do I set up the combo loader stuff ?
[01:15] <wgrant> lifeless: Should just need to set 'js.combo_loader.enabled default 0 true'
[01:15] <wgrant> May need to make combobuild, but the usual targets should do that
[01:15] <rick_h_> lifeless: which part? the actual hosting bit? or just enabling?
[01:15] <lifeless> I have a fresh lxc
[01:15] <lifeless> I've run lp-setup update
[01:15] <lifeless> and sudo make install
[01:15] <rick_h_> then it should be setup to combo build ootb. I thought the combo loading FF was on by default.
[01:15] <lifeless> I'm getting reference errors
[01:16] <lifeless> [13:14:08.562] ReferenceError: YUI is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:53
[01:16] <lifeless> [13:14:08.562] ReferenceError: LPJS is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:110
[01:16] <wgrant> Check your browser's HTTP request log
[01:16] <rick_h_> lifeless: make combobuild ?
[01:16] <lifeless> [13:14:08.330] GET https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js [HTTP/1.1 200 OK 226ms]
[01:16] <wgrant> Aha
[01:16] <wgrant> Go to that URL
[01:16] <wgrant> It probably says "missing" everywhere
[01:16] <lifeless>  /* yui/yui/yui-min.js */
[01:16] <rick_h_> and if it's missing then check build/js/...
[01:16] <lifeless>  /* [missing] */
[01:16] <rick_h_> which is what combobuild does
[01:16] <lifeless>  /* lp/meta.js */
[01:17] <wgrant> Yeah, make combobuild would be my suggestion
[01:17] <lifeless> make run doesn't do it ?
[01:17] <wgrant> Perhaps lp-setup uses a custom target that doesn't include it
[01:17] <wgrant> It should...
[01:17] <lifeless>  make combobuild
[01:17] <lifeless> utilities/js-deps -n LP_MODULES -s build/js/lp -x '-min.js' -o \
[01:17] <lifeless>         build/js/lp/meta.js >/dev/null
[01:17] <lifeless> utilities/check-js-deps
[01:17] <rick_h_> and jsbuild_watch which will should get lined up with combobuild
[01:17] <lifeless> ctrl-refresh, same stuff in that url
[01:17] <wgrant> Hm
[01:17] <wgrant> make inplace
[01:17] <lifeless> there are a lot of LP modules present
[01:17] <rick_h_> lifeless: anything in build/js?
[01:17] <lifeless> its not an empty combo response
[01:17] <wgrant> Oh
[01:18] <lifeless> var LP_MODULES = (function(){
[01:18] <wgrant> Do you have a YUI version flag set?
[01:18] <lifeless> f'r instance
[01:18] <lifeless> no
[01:18] <lifeless> neither does qastaging
[01:18] <wgrant> Right, it's not necessary
[01:19] <rick_h_> LP_MODULES is from the build/js/lp/meta.js so that's a good sign
[01:19] <wgrant> lifeless: Does the /srv/launchpad.net/convoy symlink point to a reasonable location?
[01:19] <rick_h_> lifeless: so is there anything in build/js/yui ?
[01:19] <rick_h_> maybe some failure to get that dep right?
[01:20] <lifeless> lrwxrwxrwx 1 robertc robertc 59 2012-09-28 01:18 convoy -> /home/robertc/source/launchpad/lp-branches/working/build/js
[01:20] <lifeless> ls build/js/yui
[01:20] <lifeless> yui-3.3.0  yui-3.5.1
[01:20] <wgrant> So that's all fine. Must be a buildout issue
[01:20] <wgrant> Huh
[01:20] <wgrant> yui should be a symlink to yui-3.5.1, shouldn't it?
[01:20] <lifeless> there are two instances of 'missing' in the https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js response AFAICT
[01:20] <rick_h_> no, should have build/js/yui symlink to 3.5.1
[01:21] <rick_h_> lifeless: right, yui-min.js and load-min.js are coming from the yui libary
[01:21] <rick_h_> https://launchpad.dev/+combo/?yui-3.5.1/yui/yui-min.js&lp/meta.js&yui-3.5.1/loader/loader-min.js will work since you have that dir
[01:21] <wgrant> Is build/js/yui a symlink?
[01:21] <rick_h_> but you should have the yui symlink to yui-3.5.1 as the 'default' yui version and that's missing somehow
[01:22] <rick_h_> wgrant: right
[01:22] <lifeless> build/js$ ls -ld yui
[01:22] <lifeless> drwxr-xr-x 2 robertc robertc 4096 2012-09-28 01:18 yui
[01:22] <lifeless> its a directory not a symlink
[01:22] <rick_h_> lifeless: so yea, that's the issue
[01:22] <lifeless> rm it ?
[01:22] <rick_h_> no, you need it, it needs to be the symlink, loading up my lxc to look at what makes that symlink sec
[01:22] <wgrant> On my lpsetup-created instance it's a symlink as expected
[01:23] <lifeless> well, this is bind mounted
[01:23] <lifeless> as you'd expect
[01:23] <lifeless> I've had this working tree for yonks
[01:23] <wgrant> Ah, so it's an existing checkout?
[01:23] <wgrant> Right, so I'd make clean_buildout build
[01:23] <lifeless> of course
[01:23] <rick_h_> right, clean it up and rerun then
[01:24] <rick_h_> right, combo-rootdir will do the symlink  if it doesn't exist. Since you have a directory it's failing to generate it
[01:25] <rick_h_> not sure how you got the directory there, but that's causing it to fail. a clean_buildout and make should work
[01:25] <lifeless> ok, thats a lot bigger
[01:25] <lifeless> still funky
[01:26] <lifeless> 1000 unassigned bugs is 11 seconds to render
[01:26] <lifeless> thats very interesting
[01:27] <wgrant> Bugs and people have a few enums
[01:30] <lifeless> I get Y.lp is undefined still
[01:30] <wgrant> Any [missing]s?
[01:30] <lifeless> yes
[01:30] <lifeless> between meta.js and yui/loader/loader-min.js */
[01:31] <wgrant> So meta.js is missing?
[01:31] <lifeless>  /* lp/meta.js */
[01:31] <lifeless>  /* [missing] */
[01:32] <lifeless> needed a make combobuild in that recipe you gave me
[01:33] <lifeless> 5.56 seconds now
[01:33] <lifeless> so the 10K was noise of some sort
[01:33] <lifeless> e.g. sitting on battery ;)
[02:10] <lifeless> 40% time reduction neuterin the tal in lib/lp/registry/templates/milestone-macros.pt
[02:11] <lifeless> ah, late eval queries
[02:11] <lifeless> storm cache strikes again I bet.
[02:11]  * lifeless looks for the hammer
[02:12] <wgrant> storm_cache_size
[02:12] <wgrant> configs/development/launchpad-lazr.conf
[02:12] <lifeless> yeah
[02:12] <lifeless> do you remember the prod size?
[02:12] <lifeless> [and why can't we just toss the damn thing..]
[02:12] <wgrant> 10000 I think
[02:13] <wgrant> We need *a* size
[02:13] <lifeless> well
[02:13] <lifeless> why?
[02:13] <wgrant> At least for scripts
[02:13] <lifeless> we discard the cache after every request
[02:14] <wgrant> Sure, for the webapp the limit can be quite ridiculous
[02:14] <lifeless> set a ulimit for scripts, so ones that try to do too much in one pass can fail hard
[02:14] <wgrant> For scripts it might want to be more sensible.
[02:14] <lifeless> or just have a non-discarding cache with a low fixed limit for scripts
[02:14] <wgrant> Hm
[02:14] <wgrant> Why do we still have two storm_cache_size keys...
[02:15] <wgrant> I thought I removed all the duplicates
[02:15] <lifeless> 2.5 seconds with minimal td entries
[02:15] <wgrant> What'd you change?
[02:16] <lifeless> neutered all the bug data access
[02:16] <wgrant> Ah
[02:16] <lifeless> getting a baseline for doing that many td rows
[02:16] <lifeless> 2.7 seconds with the first cell filled in
[02:16] <lifeless> same amount of HTML output
[02:17] <lifeless> running several times and taking min of course
[02:19] <lifeless>
[02:19] <lifeless>
[02:19] <lifeless>
[02:19] <lifeless>
[02:19] <lifeless> ^ 0.2 seconds over 1000 rows
[02:22] <lifeless> vs
[02:22] <lifeless>
[02:22] <lifeless>
[02:22] <lifeless>
[02:23] <wgrant> So, while I clean up this storm_cache_size stuff I think I might remove the development override
[02:23] <wgrant> It doesn't make much sense
[02:24] <lifeless> +1
[02:24] <wgrant> We keep having to work around it in tests
[02:25] <wgrant> Heh
[02:26] <wgrant> In fact, the main tests that override the limit are for ProjectMilestone:+index...
[02:29] <lifeless> wgrant: where is structure defined
[02:29] <wgrant> lifeless: In templates?
[02:29] <wgrant> Or in our Python?
[02:30] <wgrant> It's a TAL keyword; it's not defined as such anywhere
[02:30] <lifeless> the implementation
[02:32] <lifeless> emitSubstitution in talgenerator.py - closing in on it
[02:32] <wgrant> Right, it's in zope.tal
[02:33] <wgrant> Or chameleon if the page uses that
[02:33] <wgrant> But I believe that one's still zope.tal
[02:34] <lifeless> def do_insertStructure_tal(self, (expr, repldict, block)):
[02:52] <lifeless> whoa
[02:52] <lifeless> 18K permission checks
[02:52] <lifeless> I /really/ want to rip that out entirely
[02:53] <wgrant> We would need a pretty significant rewrite for that to work
[02:53] <wgrant> Plus the checks should be mostly cached, so very very fast
[02:54] <lifeless> 5.5K calls are to block implicit flushes, block implicit flushes makes 18K calls to checkPermission
[02:55] <wgrant> "makes"
[02:55] <wgrant> It's a decorator
[02:55] <lifeless> I know
[02:55] <wgrant> Ah :)
[02:56] <lifeless> there are getattr's
[02:56] <lifeless> that are blocking flushes
[02:56] <lifeless> and checking permissions
[02:56] <lifeless> 5.5% of runtime in that stack
[02:56] <lifeless> so - 'very very fast' - not so much
[02:57] <lifeless> ahha
[02:57] <lifeless> wgrant: low hanging fruit:
[02:57] <lifeless> _get_sqlobject_store
[02:57] <lifeless> wgrant: spot what it does
[02:58] <wgrant> The import could be a problem if we were multithreading, but we're not really...
[02:58] <lifeless> also block_implicit_flushes is bad too
[02:58] <lifeless> wgrant: its a lock
[02:58] <lifeless> wgrant: synchronisation primitives are not that cheap
[02:58] <wgrant> Sure
[02:59] <lifeless> wgrant: also, prod runs two threads - xmlrpc + http
[02:59] <lifeless> so we are
[02:59] <wgrant> But does the profile show that's an issue?
[02:59] <mwhudson> importing even existing modules in a tight loop is surprisingly slo
[02:59] <mwhudson> w
[02:59] <wgrant> Right, and the xmlrpc cohabitation is the root of most of our annoying undiagnosable issues
[02:59] <StevenK> mwhudson: Namespacing causes problems, news at 11?
[02:59] <wgrant> Not namespacing...
[03:02] <lifeless> wgrant: http://paste.ubuntu.com/1231593/
[03:02] <wgrant> Indeed
[03:03] <wgrant> Although I'd prefer to look at untangling the imports, that should work
[03:04] <lifeless> wgrant: its about 300ms over the request.
[03:04] <lifeless> wgrant: from a quick timeit + back of napkin
[03:05] <wgrant> Hm
[03:06] <wgrant> I've seen _get_sqlobject_store show up before in profiles, but hadn't actually looked at it as there were other dominating factors to fix first
[03:06] <wgrant> But I haven't profiled in several months
[03:07] <wgrant> Anyway, storm_cache_size is now 10000 everywhere in devel
[03:08] <wgrant> I meant to do that as followup to my DB config rework branches last year
[03:08] <wgrant> Or whenever it ws
[03:08] <wgrant> But never got around to it, apparently
[03:15] <bigjools> how often is process-upload running these days?
[03:20] <lifeless> ok so its hard to tell
[03:20] <lifeless> but it looks like it saved 100ms
[03:20] <lifeless> wgrant: ^ if you want to do it at some point
[03:20] <lifeless> I've got to context switch here
[03:21] <lifeless> hard to tell because of the massive variance
[03:29] <wgrant> bigjools: */5 for sources
[03:29] <wgrant> lifeless: Yeah, and it really really depends on the page whether it's a big issue
[03:29] <wgrant> I might try untangling that stuff
[03:30] <lifeless> it would be great to make imports barf
[03:30] <lifeless> install an import hook
[03:30] <bigjools> ta
[03:30] <lifeless> hmmm, dunno if cached imports would trigger
[03:31] <wgrant> lifeless: We have a lot of inline imports, so we can't do it generally
[03:31] <lifeless> wgrant: we could set a cap
[03:31] <lifeless> wgrant: 500 imports in a request, then boom.
[03:31] <wgrant> Yeah
[03:32] <lifeless> that would be about 5ms
[03:32] <lifeless> more or less
[03:32] <wgrant> I was initially thinking we could do a per-import cap
[03:32] <wgrant> But as you say, I'm not sure it'll actually trigger on repetition
[03:32] <wgrant> Maybe
[03:32] <lifeless> I'm not sure it will trigger at all
[03:32] <lifeless> we could hack the bytecode
[03:32] <lifeless> but folk might consider that objectionable
[03:32] <wgrant> Heh
[03:32] <wgrant> Or we could just ban inline imports in lp.services.webapp...
[03:33] <mwhudson> __import__ is called for cached imports
[03:33] <mwhudson> says science
[03:33] <lifeless> mwhudson: tried monkey patching it ?
[03:33] <lifeless> mwhudson: and we were actually speculating about pep whatsisthing hooks
[03:34] <mwhudson> oh
[03:34] <mwhudson> yeah, i just overwrote __builtin__.__import__
[03:34] <mwhudson> dunno about the hooks
[03:37] <lifeless> anyhow replacing __import__ with a thread-local-counting abomination would be effective.
[03:37] <lifeless> mwhudson: want to write one
[03:37] <lifeless> ?
[03:39] <mwhudson> i suppose i could try
[03:39] <mwhudson> where would the output go?  same place as the query count?
[03:40] <lifeless> mwhudson: Oh, I was thinking super simple: Raise a Mother* exception  :)
[03:40] <mwhudson> oh, when it crosses 500 or something?
[03:41] <lifeless> mwhudson: needs a call to install it, probably one to uninstall it, a per-thread 'request starting, kill me after X imports', and 'request finished, don't kill me anymore'
[03:41] <lifeless> mwhudson: ^ is how I would do it.
[03:43] <lifeless> http://pypi.python.org/pypi/pyjack/ is kindof related
[03:43] <lifeless> mwhudson: might want a fifth call to change the threshold mid-request
[03:43] <wallyworld__> wgrant: if you want to look https://code.launchpad.net/~wallyworld/launchpad/duplicate-bug-warning-xss-1057630/+merge/126849
[03:43] <lifeless> mwhudson: would let us featureflag it
[03:44] <lifeless> mwhudson: hmm, could minimise down to 4 calls: - install/uninstall/reset_count/set_threshold(None-or-an-int)
[03:48] <lifeless> mwhudson: make the set an attribute access, and you've got the ability to read-back too, for oops integration if we care.
[03:49] <mwhudson> lifeless: i guess there isn't a bug for this?
[03:49] <lifeless> nup
[03:52] <lifeless> man, I can't get used to this fast ->dbstable bb :)
[03:53] <mwhudson> how do you guys set things up so you can access launchpad running in an lxc from outside it?
[03:53] <mwhudson> is it just a matter of putting the right bits in /etc/hosts outside the container?
[03:53] <wgrant> wallyworld__: Might it be worth mustaching this instead? This still injects dup_id directly, which is only safe today because of constraints we place on this particular piece of data
[03:54] <wgrant> mwhudson: Right, Makefile takes a variable to make Apache listen on *, and then I drop stuff in /etc/hosts
[03:54] <mwhudson> make install LISTEN_ADDRESS=* ?
[03:55] <wgrant> Should be on https://dev.launchpad.net/Running/RemoteAccess
[03:55] <wgrant> But that looks like it
[03:55] <mwhudson> seems to be
[03:58] <mwhudson> ProgrammingError: function pg_last_xact_replay_timestamp() does not exist ?
[03:58] <mwhudson> oh
[03:58] <wgrant> You fail at 9.1
[03:58] <mwhudson> i probably haven't updated launchpad-dependencies in the container for eons
[03:58] <wgrant> Yeah
[03:58] <mwhudson> The following packages have been kept back:
[03:58] <mwhudson>  ... launchpad-database-dependencies
[03:58] <mwhudson> hm
[03:59] <wgrant> dist-upgrade?
[03:59] <mwhudson> oh right
[03:59] <mwhudson> yes, seems happier
[03:59] <wgrant> Then you'll probably want to purge 8.4, then drop and recreate the 9.1 cluster to get it on port 5432
[03:59] <wgrant> Then rerun utilities/launchpad-database-setup and all will be good
[04:01] <mwhudson> ah yes
[04:02] <StevenK> lifeless: I think db-stable should die. It's not clear what should happen to db-devel, but it's awfully heavyweight for what we want it for.
[04:03] <mwhudson> i guess what's actually going to happen here is that i'll get to the point where i could do some launchpad development
[04:03] <lifeless> StevenK: how would you assess 'db and code work well together' ?
[04:03] <mwhudson> and then it'll be time to go home
[04:04] <StevenK> mwhudson: Are you coming back to us?
[04:04] <mwhudson> StevenK: not formally :)
[04:05] <StevenK> mwhudson: Oh, so you're going to tease us with a few bug fixes? :-)
[04:05] <mwhudson> i would still like to kill the branch puller
[04:07] <StevenK> Can you kill the branch scanner too?
[04:07] <mwhudson> Get:68 http://archive.ubuntu.com/ubuntu/ lucid-updates/main libmysqlclient16 5.1.63-0ubuntu<IP_ADDRESS> [1,898kB]
[04:07] <mwhudson> whut
[04:08] <mwhudson> the path to that is less clear i think
[04:08] <StevenK> mwhudson: stub had a pretty brilliant idea, I thought
[04:08] <StevenK> mwhudson: A DB backend for bzr so when you push a branch, it directly hits the DB, no muss, no fuss
[04:09] <mwhudson> ah yeah
[04:09] <stub> I thought I was trolling?
[04:09] <mwhudson> i think i first heard that idea from mark, actually :-)
[04:09] <mwhudson> i don't know if he was trolling either
[04:09] <mwhudson> it would be awesome, but also a great deal of work
[04:09] <lifeless> bzr is a db
[04:09] <stub> In theory, it is a great idea.
[04:09] <stub> yeah, what he said
[04:09] <lifeless> so, ITYM *another* DB backend
[04:10] <StevenK> Fine, a *postgresql* backend
[04:10] <mwhudson> create table versionedfile (...)
[04:10] <mwhudson> what could go wrong
[04:10] <wgrant> So then the question becomes "oh god why"
[04:13] <mwhudson> Configuring postgresql.conf to use port 5433...
[04:13] <mwhudson> oy you
[04:13] <wgrant> Did you purge 8.4 and drop the existing 9.1 cluster?
[04:14] <mwhudson> yes
[04:14] <wgrant> :(
[04:14] <mwhudson> oh
[04:14] <mwhudson> maybe i didn't purge all of 8.4
[04:14] <stub> yeah, oh
[04:15] <mwhudson> ok, that's better
[04:20] <mwhudson> woo
[04:20] <jtv> stub: looks like my format-relative-imports branch didn't come through.  :(  I got the EC2 success message, but no landing.
[04:22] <mwhudson> um
[04:22] <mwhudson> the importfascist still exists?
[04:22] <wgrant> Yes.
[04:22] <wgrant> It doesn't do very much
[04:23] <wgrant> But it still exists
[04:23] <wgrant> And someone angered it earlier this week
[04:23] <stub> jtv: I'll try the landing step again. I too got the success message.
[04:23] <wgrant> stub, jtv: We were in testfix for several hours
[04:23] <wgrant> Probably got caught in that
[04:23] <mwhudson> database_root = 'canonical.launchpad.database'
[04:24] <stub> jtv: Do you have the mp url handy?
[04:24]  * mwhudson spots some dead code
[04:29] <mwhudson> oh yay, bootstrapping
[04:30] <jtv> stub: https://code.launchpad.net/~jtv/launchpad/format-relative-imports/+merge/124878
[04:32] <mwhudson> heh
[04:32] <mwhudson> https://code.launchpad.dev/applets -> 522 imports
[04:33] <mwhudson> or 1713 for the first request after app server startup :)
[04:37] <wallyworld__> wgrant: i could look at mustache i guess. we know the id is an int, so i saw no need to do anything special with it
[04:41] <mwhudson> lol what
[04:41] <mwhudson> one of the main offenders is get_current_browser_request doing "from zope.security.management import queryInteraction" inline
[04:41] <mwhudson> which is probably only to keep lazr.restful from unconditionally depending on zope ?
[04:42] <lifeless> wallyworld__: trusting the integrity of over the wire data is risky
[04:42] <wgrant> mwhudson: Heh
[04:43] <lifeless> mwhudson: lazr.restful shoul always depend on zope
[04:43] <wallyworld__> i guess i need to be more paranoid
[04:43] <wgrant> lifeless, wallyworld__: It's not so much the integrity of the wire. It's the fact that changing something on the server will subtly make unnecessarily fragile client code vulnerable
[04:43] <lifeless> mwhudson: the folk making it work for django were being optimists
[04:43] <mwhudson> yes
[04:43] <lifeless> wgrant: I didn't talk about integrity of the wire :)
[04:43] <lifeless> wgrant: and yes, I agree.
[04:43] <mwhudson> i think reality has won there now?
[04:43] <lifeless> mwhudson: yes
[04:44] <lifeless> mwhudson: if it were to be made separate, it would need to be several more separate projects with callbacks etc
[04:44] <wgrant> wallyworld__: eg. in a tonne of places today we inject URLs containing product names unescaped, because people thought it should be safe
[04:44] <wgrant> wallyworld__: It's a reasonable assumption, except that it means we have to be really really ultra-paranoid about project names
[04:44] <wallyworld__> sure, but a name is not an integer
[04:44] <wgrant> Because if a quote gets in one somehow, we're fucked
[04:44] <wgrant> wallyworld__: Bugs have nicknames that are used in some situation
[04:45] <wgrant> Eg. bug gbcw
[04:45] <wgrant> Or did we remove them, I can't remember.
[04:45] <wgrant> http://launchpad.net/bugs/gbcw :)
[04:45] <wgrant> Anyway
[04:45] <wgrant> Client code shouldn't be unnecessarily fragile
[04:45] <wgrant> Partly because it's possible it'll change
[04:45] <wgrant> But mostly because people will copy it
[04:46] <wgrant> And an argument that people *won't* copy it isn't really valid here, since someone clearly did copy this from elsewhere :)
[04:47] <wgrant> Launchpad is really good at convincing people to copy code :(
[04:54] <wallyworld__> wgrant: changes pushed
[04:55] <wgrant> wallyworld__: That looks much safer and even shorter, thanks.
[04:55] <wgrant> _show_comment_on_duplicate_warning still needs the same treatment, though
[04:55] <wallyworld__> np, thanks for the suggestion
[04:56] <wallyworld__> ah, ok, bug id
[04:56] <wallyworld__> will do
[04:56] <wgrant> The mustache implementation isn't precisely fast, but it should be more than fine for a dialogue like this
[04:56] <wgrant> wallyworld__: Well, you also extracted the title setting
[04:56] <wgrant> So you can merge that back in and save a line
[04:56] <wgrant> As well as handling bug_id paranoidly
[04:56] <wallyworld__> yeah, i extracted it because it failed too
[04:57] <wgrant> Indeed, thanks for finding that one.
[04:58] <stub> wgrant, lifeless: Can you think of why Deryck needs this index, when we didn't need similar ones for bug_sharing_policy and branch_sharing_policy?
[04:58] <stub> https://code.launchpad.net/~deryck/launchpad/product-specification-sharing-policy-idx-1057617/+merge/126728
[04:59] <wgrant> stub: No. It's possible it's for a garbo job, but I thought that was already done.
[05:00] <wgrant> So I'm not quite sure what's going on there
[05:00] <wgrant> It may be for adding a NOT NULL constraint or something like that
[05:00] <wgrant> (and also we established that for a product garbo job it's not worth it)
[05:00] <stub> Right. In which case a partial index might be preferable, but whatever
[05:04] <mwhudson> ok
[05:04] <mwhudson> boringly, i can report that most of the inline imports are in zope.tal :(
[05:04] <lifeless> mwhudson: really? FAARK
[05:04] <wallyworld__> wgrant: right, done
[05:04] <wgrant> mwhudson: In, or inside?
[05:04] <lifeless> mwhudson: cause, thats not peformance sensitive or anything
[05:05] <mwhudson> err
[05:05] <mwhudson> actually
[05:05] <mwhudson> pause that thought :)
[05:06] <wgrant> wallyworld__: Safer and two lines shorter. r=me. Thanks!
[05:06] <wallyworld__> thank you
[05:13] <mwhudson> wgrant, lifeless: for your confusion: http://pastebin.ubuntu.com/1231712/
[05:13] <wgrant> Rather odd.
[05:13] <mwhudson> if it 'helps'
[05:13] <mwhudson> _entnd_re = re.compile('&(#[0-9][0-9]*)(?![0-9;])')
[05:14] <mwhudson> i think the only conclusion possible here is that python is terrible?
[05:14] <lifeless> mwhudson: wtf is that doing importing ?
[05:15] <wgrant> Hm
[05:15] <wgrant> See _sre.c's call func
[05:15] <wgrant> Oh, that's just the module
[05:15] <wgrant> nevermind
[05:16] <lifeless> thats compiled already
[05:17] <lifeless> tal doing string joining won't be helping
[05:17] <lifeless> a list accumulator form of it would help I suspect
[05:17] <mwhudson>             /* not a literal; hand it over to the template compiler */
[05:17] <mwhudson>             filter = call(
[05:17] <mwhudson>                 SRE_PY_MODULE, "_subx",
[05:17] <mwhudson>                 PyTuple_Pack(2, self, ptemplate)
[05:17] <mwhudson>                 );
[05:17] <mwhudson> from _sre.c
[05:18] <wgrant> Oh
[05:18] <wgrant> Indeed
[05:18] <mwhudson> aaasd
[05:18] <mwhudson> is firefox super crashy for anyone else in precise currently?
[05:18] <wgrant> It's fine for me
[05:18] <mwhudson> hm
[05:18] <wgrant> Though I've run with Firebug disabled since the globalmenu issues
[05:18] <mwhudson> i guess my profile has eaten itself somehow
[05:18] <mwhudson> ah yea
[05:19] <mwhudson> firebug got me for a while too
[05:21] <mwhudson> anyway, on that depressing note, home time
[05:21] <wgrant> :)
[05:43] <wallyworld__> wgrant: another one https://code.launchpad.net/~wallyworld/launchpad/confirmation-dialog-xss-1057901/+merge/126855
[05:44] <wgrant> Ah right
[05:45] <wgrant> wallyworld__: r=me
[05:45] <wallyworld__> thanks
[06:26] <wgrant> IStoreSelector and co really have quite a few callsites
[06:39] <lifeless> ...
[06:40] <StevenK> Destroying SQLBase and SQLObject sounds rather more fun
[06:40] <wgrant> Not destroying
[06:40] <wgrant> Just moving
[06:40] <wgrant> To disentangle the import that lifeless was working around
[06:40] <StevenK> wgrant: Maybe you could destroy Storm and switch to SQLAlchemy
[06:40] <wgrant> Heh
[06:42] <wgrant> There we go
[06:42] <wgrant> Circular imports gone
[06:42] <wgrant> Without global hacks :)
[06:56] <StevenK> Blink
[06:56] <StevenK> How horrible is the diff?
[06:58] <wgrant> Only about 4000 lines
[06:58] <wgrant> Net -10 :)
[07:30] <wgrant> lib/lp/services/job/celeryjob.py:        from lp.services.job.celeryjob import CeleryRunJob
[07:37] <lifeless> wgrant: !
[07:44] <adeuring> good morning
[09:04] <lifeless> speaking of long requests
[09:04] <lifeless> https://oops.canonical.com/oops/?oopsid=OOPS-ddb3a4e6e473461ac93b92604efcb918
[09:04] <lifeless> wheee
[10:31] <czajkowski> mgz: is this possible ? https://answers.launchpad.net/launchpad/+question/209652
[10:38] <mgz> czajkowski: dependency resolution doesn't care about where packages come from
[10:40] <mgz> I'm not sure of bzr-builder needs extra config to look at ppas, will have a quick look
[10:43] <mgz> so, I don't think you can do remote recipe builds that need things from ppas, but it should just work locally
[10:45] <mgz> there might be specific launchpad configuration for that, generally just the main archive and sibling packages in the current ppa get used when building
[10:45] <czajkowski> mgz: ah ok
[10:46] <mgz> it's not clear from the question exactly what hes trying to do
[10:46] <mgz> but there's probably a way to do it :)
[10:53] <czajkowski> mgz: thank you
[12:11] <bac> hi adeuring.  nothing in the review queue today.  \o/
[13:17] <tumbleweed> so, what happens after my merge proposal is approved? I assume someone needs to run the test suite and land the branch?
[13:20] <cjwatson> tumbleweed: Yes - I can land it for you now if you think it's ready
[13:20] <cjwatson> tumbleweed: Unless you want to add more tests per stub's comment
[13:21] <tumbleweed> the questions that lead to that comment were more about LP style than anything else
[13:21] <tumbleweed> but yes, I suppose I did intend to add tests after finding out how I was supposed to handle it
[13:21] <cjwatson> tumbleweed: Could you set a commit message too?
[13:22] <tumbleweed> cjwatson: does it need to be in a particular format?
[13:23] <cjwatson> No, just a description.
[13:23] <tumbleweed> will do
[13:23] <cjwatson> The tools will add necessary metadata to it.
[13:24] <cjwatson> So let me know once you're happy with the test coverage ...
[13:24] <czajkowski> jcsackett:  can you look at https://answers.launchpad.net/launchpad/+question/209247  please
[13:33] <jcsackett> czajkowski: sorry, that one's outside the realm of what i can parse--i haven't done anything with packaging. :-/
[13:33] <jcsackett> czajkowski: looks like wgrant is helping them out so far though.
[13:33] <czajkowski> in theory he should be sleeping
[13:33] <czajkowski> *theory*
[13:34] <jcsackett> well, i have mentioned his name. i have noticed many people in those timezones seem to appear like magic when mentioned. :-P
[13:34] <czajkowski> lol
[13:34] <wgrant> They probably want to be sent to #ubuntu-packaging or so.
[13:35] <wgrant> As it's now nothing to do with Launchpad.
[13:35] <jcsackett> czajkowski: see? magic.
[13:36] <jcsackett> wgrant: thanks, i'll post that as a reply to the question.
[13:36] <czajkowski> jcsackett: I actualy poked you with the wrong link :/ https://answers.launchpad.net/launchpad/+question/207802
[13:36]  * jcsackett laughs
[13:36] <jcsackett> ok, let me take a look at that one.
[13:36] <czajkowski> jcsackett: you mock it's been a long week
[13:36] <jcsackett> czajkowski: not mocking, just laughing. we all have moments like that, right? :-0
[13:37] <jcsackett> s/:-0/:-)/
[13:37] <czajkowski> lol
[13:37]  * czajkowski laughs
[13:39] <tumbleweed> cjwatson: Added 1 test, everything else was already covered. And set a commit message
[13:45] <cjwatson> tumbleweed: OK, it's off to EC2 now; you'll get e-mail in four hours or so
[13:45] <tumbleweed> thanks
[13:45] <jcsackett> czajkowski: so we have a couple of bugs related to branch scanning failing, which looks to be what's happened here. on my own branches, i usually just delete the branch on LP and push a new copy to lp.
[13:45] <czajkowski> nods
[13:45] <jcsackett> czajkowski: however, they may be leery of doing that.
[13:45] <czajkowski> some font like them delted
[13:47] <jcsackett> czajkowski: it may be worth it for them to push new copies of those branches under new names temporarily to see if those scan right. in the mean time, you can point them at bug 904683 which tracks the issue.
[13:47] <_mup_> Bug #904683: Updating branch seems to last forever <Launchpad itself:Triaged> < https://launchpad.net/bugs/904683 >
[13:47] <jcsackett> czajkowski: there is also bug 1018460, but i gather this may have scanned properly initially, and so this isn't applicable.
[13:47] <_mup_> Bug #1018460: Failure during initial branch scan increases scan time enormously <branch-scanner> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1018460 >
[13:48] <jcsackett> czajkowski: and yeah, with big main branches i totally can see them not wanting to delete it--just sharing my experience. not really recommending it in this instance. :-P
[14:38] <abentley> deryck: Another formatting-related test failure that I get even on stable: http://pastebin.ubuntu.com/1247615/
[15:01] <wgrant> abentley: You're running with 2.7
[15:01] <wgrant> We only run the test suite on Python 2.6
[15:02] <abentley> wgrant: True, but yesterday deryck reported he could not reproduce my test failure even with 2.7.3 on Precise.
[15:03] <wgrant> Hmm
[15:03] <wgrant> That's certainly odd
[15:03] <abentley> wgrant: That was a different failure:  http://pastebin.ubuntu.com/1230926/
[15:04] <wgrant> That should always fail
[15:04] <wgrant> As there are no %s in the format string...
[15:05] <abentley> wgrant: Yet it hasn't.  Both the test and implementation code are years old.
[15:05] <wgrant> Ah, that branch is never meant to be hit
[15:06] <abentley> wgrant: But the test is exercising that branch.
[15:06] <wgrant> Indeed
[15:06] <wgrant> So I am very confused
[15:07] <abentley> Me too.
[15:08] <abentley> wgrant: And today's failure is equally bonkers, because "summary" behaves like a mapping in line 5, but not in line 6.
[15:11] <wgrant> Hmm
[15:11] <wgrant>   File "/home/wgrant/src/launchpad/branches/sandbox/lib/lp/code/model/branchmergeproposal.py", line 418, in setStatus
[15:11] <wgrant> That's from 2.6
[15:11] <wgrant>     raise AssertionError('Unexpected queue status: ' % status)
[15:11] <wgrant> AssertionError: Unexpected queue status:
[15:11] <wgrant> So I guess it must be treating status (which is an enum value) as a zero-length sequence
[15:13] <wgrant> And as for the other failure, I guess 2.7 is just more strict about what it wants from a mapping for formatting
[15:13] <wgrant> It is pretty odd, though
[15:15] <abentley> wgrant: How do you run with 2.6?
[15:15] <wgrant> In a Lucid LXC
[15:15] <abentley> wgrant: Ah.
[15:16] <wgrant> >>> 'foo' % BranchMergeProposalStatus.SUPERSEDED
[15:16] <wgrant> 'foo'
[15:16] <wgrant> >>> 'foo' % object()
[15:16] <wgrant> Traceback (most recent call last):
[15:16] <wgrant> >>> iter(BranchMergeProposalStatus.SUPERSEDED)
[15:16] <wgrant> Traceback (most recent call last):
[15:16] <wgrant> How odd
[15:16] <wgrant> It's not iterable, but it's 0-length?
[15:20] <abentley> wgrant: in what sense 0-length?  It doesn't support len().
[15:21] <wgrant> abentley: If it didn't think it was an iterable, then it would interpret it as a single thing to inject into the format string
[15:21] <wgrant> If it thought it was an iterable but wasn't 0-length, it'd complain that there were too many arguments
[15:21] <wgrant> So it must think it's a 0-length iterable
[15:21] <wgrant> Despite not being iterable
[18:09] <sinzui> bac do you have time to review https://code.launchpad.net/~sinzui/launchpad/merge-non-active-person/+merge/127041
[18:14] <bac> sinzui: now that i've enjoyed a fine lunch i do.
[18:15] <sinzui> thank you
[18:21] <bac> sinzui: done.  thank you.
[18:21] <sinzui> thank you bac
[19:16] <abentley> deryck: I got a test failure on EC2 that I can't reproduce locally.  Any suggestions?
[19:18] <deryck> abentley, can you email me or paste me the failure?  I'll take a look when back, going for the kids from school now.
[19:55] <deryck> abentley, back now…. looking at the mail
[19:55] <abentley> deryck: I did a second run (using -t) and it passed.  Just saw that now.
[19:56] <deryck> abentley, ah ok, cool
[19:56] <abentley> i.e. ec2 test -o '-t externalbugtracker-comment-imports.txt'
[19:57] <abentley> deryck: I hope the initial failure was due to an issue in devel that has since been resolved.
[20:00] <deryck> abentley, that's what I was wondering, if it was just timing with another failure not related to you.
[20:00] <abentley> deryck: I have no data either way.
[20:12] <sinzui> sigh. buildbot  fellover again on a different test
[20:12] <sinzui> jcsackett, I will force this build.
[20:30] <czajkowski> evening
[20:46] <abentley> deryck: In your add-product-information-type-1046467 branch, the sampledata appears to contain NULLs: http://pastebin.ubuntu.com/1248311/
[20:51] <deryck> abentley, looking.
[20:53] <abentley> deryck: (I'm getting that oops because I added a proper information_type to the model definition, but I can just mark it nullable for now.)
[20:53] <deryck> abentley, ah
[20:54] <deryck> abentley, I did this the same way I did specification_sharing_policy and relied on the garbo job, or else fixed data locally myself to play around.
[20:56] <abentley> deryck: That makes sense, I just figured you might want to fix the sampledata before landing, since you're changing it anyhow.
[20:58] <deryck> abentley, ah, fair point.  I got the success email an hour or two ago now, though.  let me see if it merged.
[21:10] <deryck> heh, I got my success mail from buildbot before I could finish registering for UDS and check pqm submit mails. :)
[22:01] <deryck> Have a nice weekend everyone.
[23:43] <cjohnston> flacoste: ping