[00:48] <cjohnston> mhall119: can you approve it and we will deal with the look later?
[00:48] <cjohnston> id like to get it packaged and released
[00:48] <cjohnston> or can i approve it
[01:14] <mhall119> cjohnston: which, the twitter branch?
[01:14] <cjohnston> ya
[01:14] <cjohnston> I just merged it
[01:14] <cjohnston> do you want to throw it up on an ec2 to test before the release?
[01:14] <mhall119> bah, another failing test
[01:16] <cjohnston> from danilos' branch?
[01:17] <mhall119> let me get a clean trunk
[01:18] <mhall119> nope, still not passing
[01:18] <mhall119> yeah, test_calculate_passes_with_multiple_plenary_rooms_if_editing
[01:18] <mhall119> danilos: ^^
[01:19] <mhall119> cjohnston: are we deploying on lucid still?
[01:19] <cjohnston> afaik
[01:21] <cjohnston> mhall119: https://code.launchpad.net/~mhall119/summit/add-lunch can you mark abandoned please
[01:30] <cjohnston> mhall119: can you throw together a test fix please
[01:32] <mhall119> cjohnston: let me look
[02:35] <mhall119> cjohnston: danilos: nigelb: http://<IP_ADDRESS>:8000/uds-p/
[02:36] <cjohnston> add a hash tag!
[02:36] <cjohnston> show all the goodness
[02:38] <cjohnston> mhall119: http://<IP_ADDRESS>:8000/uds-p/meeting/584/private-meeting/  not sure whats up with that
[02:39] <cjohnston> i guess we need if not meeting.private url, else no url
[02:39] <mhall119> it wasn't private
[02:39] <mhall119> if it was private, import_live_data wouldn't see it
[02:40] <cjohnston> so it was just called private meeting
[02:40] <mhall119> yeah
[02:40] <mhall119> see http://summit.ubuntu.com/uds-p/2011-11-01/
[02:41] <cjohnston> pl
[02:41] <cjohnston> ok
[02:53] <mhall119> cjohnston: easy fix to the test, nothing was wrong withthe code
[02:54] <mhall119> I just pushed the fix to trunk
[02:54] <cjohnston> ok
[02:54] <cjohnston> you good then with packaging it up and shipping it out?
[02:54] <mhall119> yup
[02:54] <mhall119> ask danilos when would be a good day and time to put it live
[02:54] <mhall119> then we'll see if IS can get it done then
[02:54] <cjohnston> he has a deadline of tomorrow night
[02:55] <mhall119> works for me
[03:01] <cjohnston> mhall119: http://pad.ubuntu.com/yNPpIWZRAo
[03:02] <mhall119> I think that's all we need
[03:03] <mhall119> is that what's in our typical deployment requests?
[03:03] <cjohnston> I don't remember there being anything else.. I can't find an old email
[03:03] <cjohnston> I looked through the ltp one, and the only thing im missing is the i18n stuff
[03:04] <mhall119> yeah
[03:05] <mhall119> specify the exact version number of the production branch that should be deployed
[03:06] <cjohnston> that?
[03:08] <cjohnston> does rollback need the whole file or just the #?
[03:08] <mhall119> also, add just the number, it'll revert any migrations higher than that number
[03:08] <mhall119> s/also, add//
[03:09] <cjohnston> so like it is
[03:09] <mhall119> that looks good now
[03:10] <cjohnston> i want to know how many lines of code this is
[03:10] <mhall119> bzr diff -r 161..162
[03:11] <cjohnston> i dont have enough scrollback
[03:15] <mhall119> bzr diff -r 161 --diff-options="--normal" |wc -l
[03:15] <cjohnston> mhall119: we should probably try to fix bug #917674 as its a problem this uds
[03:15] <ubot4`> Launchpad bug 917674 in summit "Longer room names are blocked by the schedule (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/917674
[03:15] <mhall119> 4300 lines
[03:15] <cjohnston> this connect
[03:15] <cjohnston> whatever
[03:15] <cjohnston> thats it?
[03:15] <cjohnston> lol
[03:17] <mhall119> we only have 12,413 lines of .py code
[03:18] <mhall119> and 2006 lines of .html
[03:20] <cjohnston> so we edited almost 1/3 of the code
[03:20] <nigelb> morning *yawn*
[03:20] <cjohnston> hey nigelb
[03:21] <mhall119> yup
[03:21] <mhall119> morning nigelb
[03:21] <mhall119> ready to deploy summit?
[03:21] <cjohnston> ready to deploy your participant fix ;-)
[03:21] <mhall119> cjohnston: be sure to cc danilos on the RT email when you send it
[03:21] <nigelb> lolno.
[03:22] <nigelb> I'm reading up on formsets
[03:22] <cjohnston> mhall119: i forgot, but i have access to add him once its triaged
[03:44] <mhall119> ok
[03:49] <mhall119> cjohnston: you good for tonight?
[07:50] <danilos> mhall119, cjohnston: the problem is likely with the test stability in  test_calculate_passes_with_multiple_plenary_rooms_if_editing
[07:51] <danilos> nigelb, hi :)
[08:17] <danilos> nigelb, did you make any progress with the formsets? If not, I'll need to look into that as well to ensure we can get it done by today
[08:23] <nigelb> danilos: hey, sorry, not yet.  I'm tryign to see if I can spare some time at work today.
[08:23] <danilos> nigelb, right, do you have a branch I can start off or should I just start from trunk?
[08:23] <nigelb> danilos: I don't have anything productive, no
[08:24] <danilos> nigelb, ack, thanks, I'll also keep you posted if I make any progress
[08:26] <nigelb> ugh
[08:27] <nigelb> who broke summit production
[08:27] <nigelb> cjohnston: ^^^
[08:35] <danilos> nigelb, probably a DB update not done, I'll check with IS
[08:36] <danilos> nigelb, btw, just adding 'participants' to the list of form fields is a minimal "add attendees" functionality as far as I can see, other than it being hard to use (Ctrl+clicking all around), any other reason why that was not considered?
[08:37] <danilos> ah, I see, saving doesn't really work
[08:37] <nigelb> yep
[08:37] <nigelb> :)
[08:37] <nigelb> I fell into the exact same trap
[10:58] <cjohnston> nigelb: dont know.. can you look into it
[10:59] <danilos> cjohnston, nigelb, heya, do you know where can we take a look at errors from the OOPSes?
[10:59] <danilos> cjohnston, nigelb: I am getting changes reverted, hopefully nothing blows up in that process either
[11:00] <danilos> cjohnston, nigelb: https://bugs.launchpad.net/summit/+bug/921502
[11:00] <ubot4`> Launchpad bug 921502 in summit "Problems with latest deployment (affects: 1) (heat: 6)" [Undecided,New]
[11:00] <cjohnston> http://paste.ubuntu.com/816311/
[11:00] <cjohnston> danilos: ^
[11:01] <danilos> cjohnston, sounds similar
[11:02] <cjohnston> danilos: there are ~100 errors that have been spent out
[11:02] <cjohnston> the few ive looked at are pretty much the same as that one
[11:02] <cjohnston> all that no    reverse match
[11:02] <danilos> cjohnston, right, I wonder why is this not failing locally
[11:03] <danilos> cjohnston, it originally 500-ed with the same error which I had a fix for cowboyed in, but then it started failing with an OOPS page
[11:06] <cjohnston> danilos: i assume you arent having any problems locally?
[11:06] <danilos> cjohnston, not with trunk, no
[11:07] <cjohnston> try production
[11:07] <danilos> cjohnston, haven't compared production
[11:07] <cjohnston> just incase its there please
[11:07] <cjohnston> I have to get the kids ready for school and leave for work in 20 minutes
[11:07] <cjohnston> im going to help as much as i can till then, but I dont know how much thatll be
[11:09] <cjohnston> one of the rrors AttributeError: 'NoneType' object has no attribute 'strftime'
[11:09] <cjohnston> http://paste.ubuntu.com/816320/
[11:10] <cjohnston> i just fired up production locally and it works
[11:13] <cjohnston> danilos: its something specific with the summit page too it looks like...
[11:13] <cjohnston> .http://summit.ubuntu.com/lcq1-12/2012-02-09/
[11:13] <cjohnston> nigelb: ^
[11:15] <danilos> cjohnston, right, I don't know what even references the missing decorator since I don't see it when grepping, and it might be specific to wsgi setup which dev setup is not using
[11:15] <danilos> cjohnston, and locally it works
[11:16] <cjohnston> danilos: did they touch the wsgi files after pushing your latest fix?
[11:16] <danilos> cjohnston, nope, not that I know of
[11:16] <cjohnston> danilos: maybe try that?
[11:16] <danilos> cjohnston, also, I only asked for it to be cowboyed in
[11:16] <cjohnston> thats fine..
[11:23] <danilos> cjohnston, that didn't help
[11:24] <cjohnston> danilos: g2g.. I'll be back as soon as I can
[11:24] <danilos> cjohnston, do you see any of the last OOPSes, I'd like to make sure I am looking at something after the change?
[11:25] <cjohnston> AttributeError: 'NoneType' object has no attribute 'strftime'
[11:26] <cjohnston> I forwarded you emails of the only different errors i can find
[11:34] <danilos> cjohnston, thanks
[11:37] <cjohnston> danilos:  I'm curious whats up with the datetime thing
[11:37] <danilos> cjohnston, it just means the value is none
[11:37] <cjohnston> why tho
[11:41] <cjohnston> danilos: email
[11:43] <danilos> cjohnston, what worries me most is the fact that "decorators" appears in all the exceptions (except the date one)
[11:45] <cjohnston> dunno
[11:45] <danilos> actually, this might explain it, there are probably different templates in use on production instance
[11:46] <cjohnston> shouldn't be
[11:50] <cjohnston> is summit.schedule.decorators.meetinng normal or is that what you were referring to
[11:53] <danilos> cjohnston, I don't know if it's normal, but it seems as if it should be referring to something else (i.e. summit.schedule.views.meeting)
[11:53] <cjohnston> agreed
[11:57] <danilos> cjohnston, hum, hum, I wonder if the old base.html is still there and is seen before the newly moved base.html in common/
[11:57] <cjohnston> do you have access to the server
[11:58] <danilos> cjohnston, nope, I have to go through IS for this
[11:58] <cjohnston> gotcha
[11:58] <cjohnston> try pinging I guess
[11:59] <cjohnston> says no vanguard tho
[12:00] <cjohnston> they bzr pull, could that leave an old one
[12:08] <danilos> nope, I've checked that, it's all fine
[12:08] <danilos> so no old templates are around
[12:08] <danilos> and this is obviously not from the old templates, I wonder what else could try to pull "summit" and "meeting" from summit.schedule.decorators
[12:08] <danilos> mhall119, ^ (when you show up)
[12:15] <cjohnston> danilos: are the imports on common.views correct
[12:16] <cjohnston> id think we would have local errors if it wasn't
[12:17] <danilos> cjohnston, yeah, also, note that every question requires some time for IS to respond
[12:18] <danilos> cjohnston, I think I'll re-ask for the reversal of the last landing, I want to focus on getting attendees adding working and then worry about deploying it all together
[12:19] <cjohnston> k
[12:59] <mhall119> ok, what happened?
[13:00] <mhall119> gah, why are reverse lookups failing?
[13:12] <cjohnston> mhall119: thoughts?
[13:12] <cjohnston> danilos: and i have both tried production locally and cant reproduce
[13:12] <cjohnston> he did already put in one fix
[13:14] <danilos> mhall119, I am not sure why would something try to get at summit.schedule.decorators.*, but it does and then fails
[13:14] <danilos> back-resolving URLs at least
[13:14] <danilos> it's fine to go there for decorators
[13:14] <danilos> but not for decorators.summit and decorators.meeting
[13:15] <danilos> mhall119, fwiw, if you've got time to look into this now, I was talking to ChrisS from IS (so he should be on top of things and might be in the process of reverting everything back)
[13:16] <cjohnston> there was an error with reverting back too
[13:16] <cjohnston> hes on lunch now
[13:16] <danilos> mhall119, (I am working on getting private attendees working)
[13:17] <cjohnston> http://paste.ubuntu.com/816407/
[13:23] <mhall119> cjohnston: danilos: using @summit_required decorator makes django think the view function exists in the decorators module (since it's wrapped by a decorator)
[13:24] <cjohnston> gotcha
[13:24] <cjohnston> is that whats causing the issue?
[13:26] <mhall119> I don't think so
[13:26] <mhall119> or it would cause it on localdev and staging too
[13:27] <mhall119> http://summit.ubuntu.com/uds-p/2011-10-31/ works fine
[13:27] <mhall119> so it can't be something from the base.html
[13:27] <mhall119> somthing in summit.html is the problem
[13:28] <mhall119> and also in meeting.html
[13:30] <cjohnston> ya
[13:30] <cjohnston> but what
[13:36] <mhall119> that I don't know
[13:42] <mhall119> oh hell, I bet I know what it is...
[13:43] <mhall119> cjohnston: are they rolling it back or what?
[13:43] <cjohnston> mhall119: there was an error with the roleback
[13:43] <cjohnston> what is it
[13:43] <cjohnston> if you can come up with a fix, we wont rollback
[13:43] <mhall119> using schedule.views.summit instead of summit.schedule.views.summit
[13:45] <cjohnston> mhall119: ill get them to change it and see
[13:46] <mhall119> I'm making the changes locally
[13:46] <mhall119> you want a patch or something they can merge into their production branch
[13:49] <cjohnston> yup
[14:14] <cjohnston> mhall119: somethings wrong with the css tho
[14:14] <cjohnston> danilos: its working
[14:18] <danilos> cjohnston, cool, thanks
[14:24] <mhall119> cjohnston: please merge my branch into production and trunk
[14:24] <cjohnston> yup
[14:24] <cjohnston> already done
[14:32] <mhall119> thanks
[15:27] <danilos> mhall119, cjohnston: btw, what happened with the colors on the wide display? also, if I am asked if we can get the wide display to be the default for Connect coming in 2 weeks, how easy would that be?
[15:28] <cjohnston> you dont want users to see the daily display?
[15:29] <mhall119> danilos: just put /display at the end of the daily view
[15:29] <mhall119> danilos: colors are defined in the Track record in the admin
[15:29] <cjohnston> danilos: the colors for the meetings? the tracks have to have colors defined
[15:31] <danilos> cjohnston, mhall119: I figured /display out (had to set connect.linaro.org to load proper URLs since they have changed), but if somebody (eg. Stephen) wants the old default back, I just wonder what should I say (because we are so close to the actual Connect, and the UI has changed significantly)
[15:31] <cjohnston> danilos: in order to see your private meetings you have to view the display
[15:31] <cjohnston> the daily
[15:31] <cjohnston> sorry
[15:32] <mhall119> ^^
[15:32] <danilos> thanks for the tips about colors
[15:32] <cjohnston> danilos: im going to start working on the layout issues on the linaro side
[15:32] <danilos> cjohnston, oh, so they don't show in the wide display for a day?
[15:32] <mhall119> danilos: no
[15:32] <danilos> ok
[15:32] <mhall119> they show as "Private Meeting" with no link or details
[15:32] <cjohnston> danilos: on the wide all it will say is Private Meeting, but you wont know who or where or what
[15:33] <mhall119> and getting that working in render.py will be a nightmare
[15:33] <mhall119> besides, the wide view horrible for desktop use anyway
[15:34] <danilos> mhall119, well, imho, it has its uses, I agree it's not perfect for looking at "your own" schedule
[15:36] <mhall119> danilos: if they have a serious issue with the new schedule, I'll of course do what we can to help
[15:36] <mhall119> but if it's just "omg change!", that's going to be hard to justify
[15:36] <danilos> btw, where did the BP link go? maybe it's just epiphany rendering issue
[15:36] <mhall119> danilos: it's not in display anymore, it's on the meeting page
[15:36] <danilos> mhall119, well, if it's "omg change 10 days before Connect!", I'd call it a little bit more founded :)
[15:36] <mhall119> display is just that, for display
[15:37] <mhall119> danilos: in that case we can roll back to the previous production version until after connect
[15:38] <danilos> mhall119, right, and lose the private meeting stuff :) so, I won't speculate anymore and I'll hope nobody complains
[15:38] <mhall119> me too :)
[15:38] <mhall119> danilos: honestly if it's a deal breaker we can work something in
[15:38] <danilos> mhall119, btw, it'd be nice if BP links worked in the edit interface, I used to use the "display" interface to subscribe to sessions I care about by loading the blueprints directly from that one page
[15:39] <mhall119> danilos: we can add it to the new schedule table
[15:39] <danilos> mhall119, yeah, I am not worried about that too much, just trying to be prepared for potential questions
[15:40] <danilos> mhall119, it would be nice if we can make the hover pop-up there stick and have link to a blueprint and similar
[15:41] <danilos> anyway, back to getting private attendees working: I got it mostly working, I just need to restrict the attendees to those for that particular summit
[15:42] <mhall119> danilos: they'll "stick" as long as your mouse is over it
[15:42] <mhall119> we can either add the blueprint link in the pop-up, or next to the meeting name in the table
[15:43] <cjohnston> mhall119: we need to restrict the people in managers and schedulers to attendees.. its way too long
[15:43] <danilos> mhall119, heh, I guess that depends on the font size and browser rendering, since there seems to be some space between it and session name for me and it disappears before I can move the mouse on top of it
[15:43] <mhall119> cjohnston: we can just order them by username
[15:44] <mhall119> danilos: ok, it's a pretty simple thing, we can introduce a jquery-ui widget in it's place in a future release
[15:44] <cjohnston> its still a gazillion people to try to pick 20
[15:45] <mhall119> cjohnston: technically it shouldn't be you that has to do it
[15:45] <cjohnston> already got a complaint
[15:47] <mhall119> from who?
[15:48] <cjohnston> arwen
[15:49] <mhall119> about setting managers?
[15:51] <mhall119> cjohnston: you should have access to leads in the admin now
[15:51] <cjohnston> ty
[17:58] <cjohnston> danilos: https://code.launchpad.net/~chrisjohnston/ubuntu-community-webthemes/linaro-fixes/+merge/90165
[17:58] <cjohnston> We need to get those changes into production to unbreak the linaro side
[18:00] <danilos> cjohnston, looking, I'll have the attendee stuff shortly as well
[18:00] <cjohnston> awesome
[18:09] <danilos> cjohnston, looks good to me as well, nothing beats trying it out though :)
[18:09] <cjohnston> I'm not entirly sure how to try it, other than just replace ubuntu_website with it
[18:19] <cjohnston> danilos: im testing it locally
[18:19] <danilos> cjohnston, right, cool
[18:21] <cjohnston> danilos: everything looks good
[18:21] <danilos> cjohnston, great
[18:21] <cjohnston> mind merging it and asking IS to update the branch?
[18:24] <danilos> cjohnston, I am hoping to be done with my branch soon, so I'd rather focus on that still, and then get it all merged
[18:24] <cjohnston> ok
[18:24] <danilos> cjohnston, also, I don't have access to merge it anywhere myself
[18:24] <cjohnston> they are seperate branches and seperate process
[18:24] <cjohnston> processes
[18:25] <danilos> cjohnston, ah, right
[18:25] <cjohnston> your the owner to the team that is the owner of the branch
[18:25] <danilos> cjohnston, sure, I'll get that updated as well
[18:25] <cjohnston> :-)
[18:25] <cjohnston> ty
[18:25] <cjohnston> the private meeting page will thank you
[18:25] <cjohnston> lol
[18:41] <danilos> cjohnston, nigelb_, mhall119: https://code.launchpad.net/~danilo/summit/private-attendees/+merge/90183
[18:41] <danilos> unfortunately, I didn't have any time to get the tests done (or even started)
[18:43] <cjohnston> danilos: ill test it
[18:43] <danilos> cjohnston, thanks, I've tested it as well, but I'll appreciate someone looking it over as well
[18:45] <cjohnston> ok
[18:45] <cjohnston> danilos: mind testing my two https://code.launchpad.net/summit/+activereviews
[18:45] <cjohnston> they are both just cleanup items that since we are going to push a release we might as well
[18:47] <danilos> cjohnston, LP is peculiarly slow for me now, pages loading...
[18:47] <cjohnston> hrm
[18:48] <cjohnston> danilos: so the linaro theme is good to go, just needs to be asked of IS
[18:49] <danilos> cjohnston, I also wonder if we need to update the theme or what for the top bar to point to lcq1-12 and not uds-q
[18:49] <cjohnston> danilos: i was trying to figure out how to do that
[18:50] <cjohnston> danilos: maybe pull the links out of base.html and put them into a header.html file?
[18:51] <cjohnston> danilos: are these particpants being marked as required?
[18:52] <danilos> cjohnston, yes
[18:52] <cjohnston> what did you mean about the displaying?
[18:53] <cjohnston> dude.. it looks awesome
[18:53] <cjohnston> mhall119: do you want to test it out?
[18:53] <cjohnston> ive created a meeting and added people, then gone back and edited the meeting, removed some of the initial people, and added some more people
[18:53] <mhall119> cjohnston: if you're happy, I'm happy
[18:54] <cjohnston> ok
[18:54] <mhall119> cjohnston: can we use his code as the basis for moving more stuff out of the admin?
[18:55] <cjohnston> mhall119: i think so
[18:55] <mhall119> cool
[19:01] <cjohnston> danilos: im going to work on some help text too
[19:02] <danilos> cjohnston, I meant that I don't see on the regular meeting page who the attendees are, even if I am an admin or a participant
[19:02] <cjohnston> i saw it
[19:02] <cjohnston> below the pad
[19:03] <cjohnston> danilos: do you want us to add in the ability to define what etherpad to use for a summit? that way pad.l.o can be used?
[19:03] <danilos> cjohnston, yes, please!
[19:04] <cjohnston> ok
[19:04] <cjohnston> give me a bit and ill have a couple more MPs for review
[19:04] <knome> ministers of parliament?
[19:04] <danilos> cjohnston, ah, ok, just me being blind :)
[19:04] <danilos> knome, nope, Municipality Police (Officers)
[19:05] <knome> he
[19:05] <danilos> cjohnston, to get https://code.launchpad.net/~chrisjohnston/summit/921663/+merge/90185 to work I had to do one simple change (i.e. add ".count" or the if condition always passed)
[19:06] <cjohnston> hrm.. ok
[19:06] <cjohnston> it was workin fine for me
[19:08] <danilos> cjohnston, right, I don't know enough of the django templating to explain it, but without .count it didn't work (it showed all the empty "Lead:" lines on the tracks page), with it, it did (it should also be faster I suppose, though still far from optimal approach for rendering a page)
[19:10] <mhall119> danilos: without .count, the variable you're testing is an instance of RelatedModelManager
[19:10] <mhall119> as a non-None object, it will resolve to True in a logic test
[19:10] <danilos> mhall119, right, I assume something like that, I wonder why did it work for cjohnston in his testing
[19:11] <mhall119> wait, having .all should accomplish the same thing
[19:11] <mhall119> you don't need .all if you have .count
[19:11] <danilos> mhall119, I wonder if there's something faster than count() for django ORM (something like .any() in Storm)
[19:11] <mhall119> .all returns (IIRC), a QuerySet instance
[19:11] <cjohnston> nigelb_: could you please smack tarmac
[19:12] <mhall119> danilos: .count() in django ORM does the count in the SQL, so it's as fast as we can get
[19:12] <danilos> mhall119, you can be faster, you can do COUNT LIMIT 1, that's what Storm does ;)
[19:12] <mhall119> unless you have .all() before .count(), in which case it's already loaded all the results
[19:13] <mhall119> but COUNT without GROUP BY will always return just one result
[19:13] <knome> count(*) ?
[19:13] <danilos> mhall119, no, no, I mean you can LIMIT 1 the results that you are counting
[19:13] <mhall119> oh, so count is 0 or 1, I gotcha
[19:14] <mhall119> you can try track.lead_set.all.0
[19:14] <mhall119> that doesn't have the count, but should do LIMIT 1
[19:15] <danilos> mhall119, right, that was just me being curious
[19:15] <danilos> cjohnston, anyway, I get just .all() to work now as well, maybe it's some browser caching on my side, sorry
[19:15] <mhall119> danilos: it's not like it matters, since we're going to step through and display all the results anyway
[19:16] <danilos> mhall119, indeed
[19:16] <mhall119> in fact, using .all in the if will have django cache the results for the inner for loop
[19:16] <mhall119> so only one query
[19:16] <mhall119> where as with .count it would be 2
[19:16] <danilos> mhall119, yep, I was mostly worried that it didn't work, and it started working when I introduced the count, if we are to worry about performance, we shouldn't do a single query for each track :)
[19:17] <mhall119> ah, the jfun of django internals
[19:17] <danilos> anyway, let me get the theme updated
[19:19] <danilos> mhall119, cjohnston: if you are fine with the private attendees change, can you perhaps arrange for it to be updated?
[19:19] <danilos> mhall119, cjohnston: btw, what was the problem with it in the morning?
[19:20] <cjohnston> schedule.views.something instead of summit.schedule.views.something
[19:20] <cjohnston> danilos: as soon as tarmac comes around it will merge the MP
[19:20] <cjohnston> I'm working right now on the help text
[19:20] <cjohnston> then ill go back and fix my track lead thing
[19:20] <cjohnston> then ill add the etherpad thing
[19:20] <cjohnston> then ill make someone do a bunch of reviews
[19:21] <cjohnston> then ill make it all go live
[19:24] <danilos> cjohnston, as mhall119 noted, nothing seems to need to change for the track lead thing
[19:25] <cjohnston> ok.. so then it can be merged as is?
[19:25] <cjohnston> i missed that convo
[19:25] <danilos> cjohnston, yes, it can
[19:26] <cjohnston> ok
[19:37] <cjohnston> mhall119: anything against renderablemixin?
[19:41] <danilos> cjohnston, I'll have to drop out in a minute or two, I'll come back online from home, but I'd appreciate if you guys can get the stuff merged into production branch and file an RT CCing me as well :) if not, I can do at least the part regarding the RT, but I can't land stuff to production branch
[19:41] <cjohnston> will do
[19:41] <cjohnston> :-)
[19:42] <danilos> cjohnston, thanks
[19:43] <cjohnston> danilos: still here
[19:44] <cjohnston> mhall119: do we want participants on private meetings to be required, or leave it unrequired so that they can edit it later
[19:46] <cjohnston> danilos: ^
[20:03] <mhall119> cjohnston: can we put the required flag on the form?
[20:04] <cjohnston> it currently is required
[20:04] <mhall119> cjohnston: I don't have a problem with bringing renderablemixin to summit
[20:04] <mhall119> cjohnston: that would seem a reasonable default to me, but why can't we have the checkbox like in the admin?
[20:04] <cjohnston> im trying to figure out how to make the page show it as required
[20:04] <cjohnston> no..
[20:04] <cjohnston> requiring adding a participant
[20:04] <cjohnston> not marking a participant as required
[20:05] <mhall119> oh, I understand now
[20:05] <mhall119> I'd say no
[20:05] <cjohnston> hrm
[20:05] <cjohnston> i agree
[20:05] <cjohnston> i gotta figure out how
[20:05] <mhall119> they're not very useful without a participant, but maybe they need to reserve a room for a hour to meet with someone not in LP or Summit
[20:06] <cjohnston> thats what im thinking
[20:06] <cjohnston> or if they dont know who will be involved
[20:06] <cjohnston> i think im gonna need some help mhall119
[20:07] <mhall119> does danilos have time?
[20:07] <mhall119> I've got some catching up to do with my actual work
[20:09] <cjohnston> he is headed home
[20:09] <mhall119> if it's not a bid deal for connect, we can fix it for uds-q
[20:10] <cjohnston> its missing a lable
[20:10] <cjohnston> label
[20:10] <cjohnston> for participant
[20:10] <cjohnston> s
[20:11] <cjohnston> i can wait for danilos
[20:26] <cjohnston> danilos: when you get back let me know please.. i requested that the theme be updated too
[20:30] <danilos> cjohnston, I've requested that earlier, lamont tells me it should be done, can you please confirm?
[20:31] <cjohnston> danilos: doesnt seem to be
[20:31] <cjohnston> there is now an RT for it
[20:32] <danilos> cjohnston, what in particular did you expect to change?
[20:32] <cjohnston> http://summit.linaro.org/lcq1-12/create_pm/
[20:32] <cjohnston> http://summit.linaro.org/lcq1-12/2012-02-06/
[20:32] <cjohnston> both should look nicer
[20:32] <danilos> that all looks fine to me (and it did earlier as well), let me try a different browser
[20:33] <cjohnston> im on chromium and it looks bad
[20:33] <cjohnston> it should pretty much match summit.u.c
[20:34] <danilos> cjohnston, it does for me, other than the footer
[20:34] <cjohnston> hrm
[20:34] <danilos> looks the same in chromium as well
[20:38] <danilos> then again, http://summit.linaro.org/media/css/ doesn't list the newly added 960.css
[20:38] <danilos> cjohnston, but neither does it from summit.ubuntu.com
[20:38] <cjohnston> danilos: does it look like http://ubuntuone.com/16tDRt3MhIBAz2sWeiR6l4
[20:39] <danilos> cjohnston, ok, I was looking at the wrong path, it's all there: http://summit.linaro.org/ubuntu-website/media/css/
[20:39] <cjohnston> hrm
[20:41] <danilos> cjohnston, nope, it looks like people.linaro.org/~danilo/summit/linaro-css.png
[20:42] <cjohnston> i wonder whats wrong with my browser
[20:42] <cjohnston> ive even cleared cache
[20:42] <cjohnston> oh well
[20:43] <danilos> cjohnston, you need to buy yourself a newer version, that one is broken :) I can sell you mine cheap
[20:43] <cjohnston> lol
[20:44] <cjohnston> danilos: can you fire up a branch that has your new attendee stuff, and merge in lp:~chrisjohnston/summit/this-adds-help-text
[20:45] <danilos> cjohnston, it'll take me a while to get everything set up on the laptop here, but sure
[20:45] <cjohnston> ok
[20:46] <danilos> cjohnston, actually, pulling the data for the sprint from LP and live instance is going to take a bit
[20:46] <cjohnston> danilos: i can give you a db
[20:47] <cjohnston> danilos: http://ubuntuone.com/0NNoVKVtXBx7l9jap6i3WG
[20:48] <danilos> cjohnston, thanks
[20:51] <cjohnston> danilos: its admin/password to get into the admin area, then you will have to add staff and can change agenda, or can change schedule, i forget which it is, to your user after you login for the first time
[20:53] <cjohnston> let me know when you get all that done please
[20:58] <danilos> cjohnston, I did get it all done
[20:58] <cjohnston> ok...
[20:58] <cjohnston> go to the create private meeting form in the ui please
[20:59] <danilos> cjohnston, I am on it, I can see the help icons, but the "Participants" label is gone
[20:59] <cjohnston> thats one of the two things i need help with
[21:00] <cjohnston> figure out how to get that back
[21:00] <cjohnston> and we want to make it not required to add a participant
[21:03] <danilos> cjohnston, that's not the right "required" param you are changing, that one is participation_essential basically
[21:04] <cjohnston> the one that i changed to false?
[21:04] <cjohnston> ok.. changed that back
[21:07] <danilos> cjohnston, http://paste.ubuntu.com/816981/ are the changes required to get the label back and make the field not be required
[21:09] <danilos> (the second part is restoring that required value that you already changed back)
[21:21] <danilos> cjohnston, I'm about to leave the computer, is there anything else I can help you with?
[21:21] <cjohnston> i just made an MP
[21:21] <cjohnston> thats it
[21:21] <cjohnston> it needs a review, I'll do the etherpad thing and then we will be ready to release
[21:22] <danilos> cjohnston, ack, is there someone else who can review it or do you want me to do it?
[21:22] <cjohnston> mhall119: might be able to later
[21:22] <cjohnston> not sure
[21:25] <danilos> cjohnston, for my personal sense, including so much new JS and CSS is not worth it for the differently colored tooltips, but that's just me :)
[21:26] <danilos> cjohnston, I won't look at those since I assume you just copied them directly
[21:26] <cjohnston> its all copied from loco.ubuntu.com
[21:27] <cjohnston> danilos: we are wanting to move 99% of the stuff out of the admin area, so they need to come at some point anyway
[21:27] <cjohnston> and if i don't do it now, i gotta figure out how to style to help text
[21:27] <danilos> cjohnston, right, I approved the code changes, I haven't looked at the JS nor CSS :)
[21:28] <cjohnston> ty
[21:31] <danilos> cjohnston, I reviewed the other outstanding MP you had as well
[21:31] <cjohnston> ty
[21:32] <danilos> cjohnston, I am off now, I hope I'll wake up to a fully updated production :P
[21:32] <danilos> have a nice day
[21:32] <cjohnston> have a good night
[21:34] <mhall119> cjohnston: the staging box is updated to the latest trunk
[21:43] <cjohnston> cool


[07:57]  * Laney turns off auto-sync
[08:10] -queuebot:#ubuntu-release- New sync: servlet-api (disco-proposed/primary) [4.0.1-2]
[08:10] -queuebot:#ubuntu-release- New: accepted golang-github-codahale-hdrhistogram [amd64] (disco-proposed) [0.0~git20161010.3a0bb77-1]
[08:10] -queuebot:#ubuntu-release- New: accepted golang-github-uber-go-atomic [amd64] (disco-proposed) [1.3.2+git20181018.8dc6146-1]
[08:10] -queuebot:#ubuntu-release- New: accepted servlet-api [sync] (disco-proposed) [4.0.1-2]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [arm64] (disco-proposed) [0.43.90-1]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [i386] (disco-proposed) [0.43.90-1]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [s390x] (disco-proposed) [0.43.90-1]
[08:10] -queuebot:#ubuntu-release- New: accepted golang-github-crossdock-crossdock-go [amd64] (disco-proposed) [0.0~git20160816.049aabb-1]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [amd64] (disco-proposed) [0.43.90-1]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [ppc64el] (disco-proposed) [0.43.90-1]
[08:10] -queuebot:#ubuntu-release- New: accepted golang-github-yudai-golcs [amd64] (disco-proposed) [0.0~git20170316.ecda9a5-1]
[08:10] -queuebot:#ubuntu-release- New: accepted vala [armhf] (disco-proposed) [0.43.90-1]
[08:23] -queuebot:#ubuntu-release- New binary: servlet-api [amd64] (disco-proposed/universe) [4.0.1-2] (no packageset)
[08:30] -queuebot:#ubuntu-release- New: accepted servlet-api [amd64] (disco-proposed) [4.0.1-2]
[08:31] <rbasak> Now that autosync is off, could an AA look at bug 1813317 pretty please.
[08:32] <rbasak> We're doing some work on src:php7.2 so it'd be nice to be able to catch any issues from 7.3 removal in case it causes problems.
[08:32] <rbasak> (hopefully not because they're separated dependency-wise)
[08:49] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[08:50] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.6] (20190222) has been added
[08:52] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.6] (20190222) has been added
[09:01] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:03] <Odd_Bloke> Does someone have a minute to look at https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 so we can get vagrant out of -proposed, please?
[09:05] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[09:05] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:06] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[09:06] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:06] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[09:06] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:11] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.6] (20190222) has been added
[09:11] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.6] (20190222) has been added
[09:13] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.6] (20190222) has been added
[09:18] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[09:18] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:19] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.6] (20190222) has been added
[09:19] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.6] (20190222) has been added
[09:32] <bdmurray> xnox: Were you going to update bug 1790831?
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.6] (20190222.1) has been added
[09:35] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.6] (20190222.1) has been added
[09:41] <ogra> infinity, initramfs-tools-devices looks so lonely in https://launchpad.net/ubuntu/disco/+queue ... it wants to cuddle with the other packages in the archive ...
[09:42] <infinity> ogra: Maybe it should learn to love itself, then others might love it more.
[09:42] <ogra> ha
[10:31]  * sil2100 is fixing the ubuntu-gnome .6 builds
[10:31] <sil2100> I'll also try re-running mythbuntu, since that one seemed to be more of a transient failure (in case anyone wants to test that one)
[10:35] -queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (bionic-proposed/universe) [0.11-1 => 1.0.3-0ubuntu0.1] (ubuntugnome)
[10:37] -queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-gtk (bionic-proposed/universe) [0.11-1 => 1.0.2-0ubuntu1.1] (ubuntugnome)
[10:39] -queuebot:#ubuntu-release- New source: xdg-desktop-portal-gtk (xenial-proposed/primary) [1.0.2-0ubuntu0.0]
[10:39] -queuebot:#ubuntu-release- New source: xdg-desktop-portal (xenial-proposed/primary) [1.0.3-0ubuntu0.0]
[11:02] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.6] (20190222.1) has been added
[11:02] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.6] (20190222.1) has been added
[11:02] <sil2100> \o/
[11:15] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.6] (20190222.1) has been added
[11:15] -queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.6] has been updated (20190222.1)
[12:11] <jbicha> sil2100: .6?
[12:12] <jbicha> is it apt?
[12:16] <juliank> autopkgtest cloud workers were broken for 10,20 mins. Sorry for the inconvenience
[12:38] <infinity> jbicha: Yes, apt. :/
[12:41] <juliank> infinity: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_administration, "Journal log analysis"
[12:41] <juliank> journalctl ADT_PACKAGE=autopkgtest :)
[12:42] <juliank> vorlon, sil2100, Laney ^ documentation for what fields we have now in the journal on the cloud worker
[12:42] <juliank> Merge request: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/363546
[12:43] <juliank> We might want to parse the params we get and add more useful field than stuff that json into that journal field
[12:54] -queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.14.2-0ubuntu<IP_ADDRESS> => 0.22.2-1ubuntu0.1~ubuntu16.04.1] (no packageset)
[12:54] -queuebot:#ubuntu-release- Unapproved: python-certbot (xenial-proposed/universe) [0.14.2-0ubuntu<IP_ADDRESS> => 0.23.0-1~ubuntu16.04.1] (no packageset)
[12:54] -queuebot:#ubuntu-release- Unapproved: python-certbot-apache (xenial-proposed/universe) [0.14.2-0ubuntu<IP_ADDRESS> => 0.23.0-1~ubuntu16.04.1] (no packageset)
[12:55] -queuebot:#ubuntu-release- New source: python-josepy (xenial-proposed/primary) [1.1.0-1ubuntu<IP_ADDRESS>]
[12:57] -queuebot:#ubuntu-release- Unapproved: python-letsencrypt-apache (xenial-proposed/universe) [0.4.1-1ubuntu<IP_ADDRESS> => 0.7.0-0ubuntu<IP_ADDRESS>] (no packageset)
[12:57] -queuebot:#ubuntu-release- Unapproved: python-letsencrypt (xenial-proposed/universe) [0.4.1-1ubuntu<IP_ADDRESS> => 0.7.0-0ubuntu<IP_ADDRESS>] (no packageset)
[13:04] -queuebot:#ubuntu-release- New binary: jsp-api [amd64] (disco-proposed/universe) [2.3.4-2] (no packageset)
[13:04] -queuebot:#ubuntu-release- New: accepted jsp-api [amd64] (disco-proposed) [2.3.4-2]
[13:33] -queuebot:#ubuntu-release- Unapproved: openssl1.0 (cosmic-proposed/main) [1.0.2n-1ubuntu6.1 => 1.0.2n-1ubuntu6.2] (core)
[13:52] -queuebot:#ubuntu-release- Unapproved: openssl1.0 (bionic-proposed/main) [1.0.2n-1ubuntu5.2 => 1.0.2n-1ubuntu5.3] (core)
[14:07] -queuebot:#ubuntu-release- New: rejected python-josepy [source] (xenial-proposed) [1.1.0-1ubuntu<IP_ADDRESS>]
[14:09] -queuebot:#ubuntu-release- New source: python-josepy (xenial-proposed/primary) [1.1.0-1~ubuntu16.04.1]
[14:12] -queuebot:#ubuntu-release- Unapproved: rejected python-acme [source] (xenial-proposed) [0.22.2-1ubuntu0.1~ubuntu16.04.1]
[14:14] -queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.14.2-0ubuntu<IP_ADDRESS> => 0.22.2-1ubuntu0.1~16.04.1] (no packageset)
[14:14] -queuebot:#ubuntu-release- New: accepted python-josepy [source] (xenial-proposed) [1.1.0-1~ubuntu16.04.1]
[14:16] -queuebot:#ubuntu-release- New binary: python-josepy [amd64] (xenial-proposed/none) [1.1.0-1~ubuntu16.04.1] (no packageset)
[14:20] <LocutusOfBorg> autopkgtest [11:22:09]: ERROR: "sh -ec mkdir -p /etc/apt/preferences.d; PKGS=""; PKGS="$PKGS $(apt-cache showsrc libmarc-xml-perl | awk '/^Package-List:/ { show=1; next } (/^ / && show==1) { print $1; next } { show=0 }' |sort -u | tr '\n' ' ')"; printf "Package: $PKGS\nPin: release a=disco-proposed\nPin-Priority: 995\n" > /etc/apt/preferences.d/autopkgtest-disco-proposed; printf "
[14:20] <LocutusOfBorg> Package: *\nPin: release a=disco-updates\nPin-Priority: 990\n" >> /etc/apt/preferences.d/autopkgtest-disco-proposed; " failed with stderr "E: You must put some 'source' URIs in your sources.list
[14:20] <LocutusOfBorg> this looks awesome
[14:20] <LocutusOfBorg> https://autopkgtest.ubuntu.com/packages/libmarc-xml-perl/disco/arm64 <-- here
[14:21] <LocutusOfBorg> also here https://autopkgtest.ubuntu.com/packages/libmarc-charset-perl/disco/ppc64el and many other places..
[14:24] <infinity> LocutusOfBorg: Known, and vorlon is/was/did fixing/fix it.  Ish.
[14:25] -queuebot:#ubuntu-release- Unapproved: glewmx (bionic-proposed/universe) [1.13.0-4 => 1.13.0-4ubuntu<IP_ADDRESS>] (no packageset)
[14:25] -queuebot:#ubuntu-release- Unapproved: glewmx (cosmic-proposed/universe) [1.13.0-4 => 1.13.0-4ubuntu<IP_ADDRESS>] (no packageset)
[14:26] <vorlon> yes, that's been fixed
[14:26] <vorlon> but not the bug in the script that allowed the broken image to be created
[14:29] -queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (xenial-proposed) [0.22.2-1ubuntu0.1~16.04.1]
[14:30] -queuebot:#ubuntu-release- Unapproved: accepted python-certbot [source] (xenial-proposed) [0.23.0-1~ubuntu16.04.1]
[14:31] -queuebot:#ubuntu-release- New: accepted python-josepy [amd64] (xenial-proposed) [1.1.0-1~ubuntu16.04.1]
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted python-certbot-apache [source] (xenial-proposed) [0.23.0-1~ubuntu16.04.1]
[14:32] -queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt [source] (xenial-proposed) [0.7.0-0ubuntu<IP_ADDRESS>]
[14:32] -queuebot:#ubuntu-release- Unapproved: accepted python-letsencrypt-apache [source] (xenial-proposed) [0.7.0-0ubuntu<IP_ADDRESS>]
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.6] has been disabled
[14:40] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.6] has been disabled
[14:45] <jbicha> (I disabled the Ubuntu GNOME 16.04.6 builds)
[15:01] <LocutusOfBorg> vorlon, will you kick tests again once is fixed?
[15:01] <vorlon> it's already fixed. tests already kicked.
[15:05] <jbicha> please remove birdfont/s390x from disco-proposed it's correctly in depwait now
[15:06] <jbicha> sorry, birdtray
[15:06] <jbicha> the thunderbird thingy not the font thingy
[15:07] <acheronuk> vorlon release team et al. Just a FYI so you knoe it is coming... Kubuntu would like a freeze exception for the KDE PIM (email/rss/contacts etc) stack. I will do a FFE bug in the next few days. this will be 59 source packages, which sound a lot but we have followed debian on dropping autopkgtests from most of those, so it should not be a big strain on the infra
[15:19] <acheronuk> Laney: you will no doubt be pleased to hear that about the tests ^^. ~38 were nuked. I am also sorry that I have not responded to your email. recent family bereavement has meant that I have been doing a bar minimum here. I will try my best in the next few months to review what tests are useful, and which are not
[15:19] <acheronuk> *bare minimum
[15:23] <acheronuk> I would note that removing the PIM tests cut the amount of rdep tests generated by the last frameworks update by about 40%. If the non x86 infra had not had a network meltdown just after I uploaded, most queues would have cleared in a day or 2
[16:18] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.6] has been disabled
[16:18] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.6] has been disabled
[16:40] <tomreyn> there are some people in #ubuntu reporting their xenial instrallations using some kind of automation are failing due to broken installers. were broken 16.04.6 builds released at some point during the past 3 days?
[16:56] <Eickmeyer> tomreyn: I think I read something about that in the mailing list that there had to be a respin due to some breakages, but don't quote me on that.
[16:56] <tomreyn> Eickmeyer: thanks for responding. that's ubuntu-release@lists ?
[16:57] <Eickmeyer> Yes.
[18:15] <jbicha> vorlon: it doesn't look like ppc64el is fixed
[20:15] <tomreyn> more reports on the broken xenial mini.iso - https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1816846 - 41 people confirming so far (and i assume this bug is filed against the wrong package, should it not be "debian-installer")
[20:35] <vorlon> jbicha: what are you seeing on ppc64el?
[20:50] <jbicha> vorlon: there's lots of red on excuses, here's a result that's a little older now but still after the time you said things were fixed: https://autopkgtest.ubuntu.com/packages/g/gnome-photos/disco/ppc64el
[20:51] <vorlon> ok.  I didn't realize those images had also gotten broken; I'll fix them now
[20:52] <jbicha> I think s390x too but some of the s390x tests passed 🤷
[21:01] <vorlon> because s390x has two cloud regions and I only managed to break images in one of them
[21:02] <jbicha> thank you
[21:04] <tsimonq2> infinity, vorlon: Do I still have permission to approve/deny FFes for Kubuntu packages like last cycle?


[05:05]  * poolie reads eric's patch
[05:49] <poolie> hi spiv?
[05:50] <spiv> Hi poolie
[05:52] <poolie> hey, how are you?
[05:55] <spiv> A bit thwarted; it turns out I still haven't got a local reproduction of bug 653307 yet after all.  And earlier today I thought it might be interesting to quickly try make a small update to one of the lpstats graphs and didn't find the relevant code/branch among those listed in the wiki.
[05:56] <spiv> So I set my sights a bit lower for today and have bzr-usertest passing tests again and my old outstanding network-suite branch merged with current trunk, and about to see if it still does what it's supposed to.
[05:57] <poolie> hm, i think you want lp:tuolumne-lp-configs
[05:57] <poolie> i'm doing some low fruit in kanban at the moment
[05:57] <poolie> trying to get it running more frequently and faster
[05:57] <poolie> ah i saw some action there
[05:57] <spiv> That's what I thought, but I don't see any sign of the CodehostingConnections stats in there.
[05:57] <poolie> it would be nice if it was easy to reproduce
[06:00] <poolie> i guess you'd have to ask a losa where it's configured
[06:00] <poolie> possibly actually tom
[06:00] <poolie> it might be injected into the database by some other means
[06:00] <spm> hm?
[06:01] <spiv> (I did at least confirm that graphs for longer time periods will show misleadingly shallow spikes for brief-but-high spikes because it just collapses multiple data points to the mean)
[06:01] <poolie> spm, do you know where the code that injects CodehostingConnections into tuolumne is?
[06:01] <poolie> and hi!
[06:01] <spm> ah. the collection script probably isn't publically available.
[06:01] <spm> heh, heya
[06:01] <spm> it's pretty simple, one sec, will paste.
[06:03] <spm> spiv: https://pastebin.canonical.com/43318/
[07:51] <vila> hi all !
[08:54] <mneptok> When the light of life has gone, no change from the meter. Then the King Of Spivs will come, seeling blood by the liter.
[09:08] <vila> mneptok: should mention a goat or two when summoning like that ?
[09:10] <mneptok> vila: do you have something against goats? why would you subject them to that?
[09:11] <vila> mneptok: nothing against, quite the contrary, they work far better than chickens for my needs
[09:11] <mneptok> vila: and last i knew, due to problems at an All-Hands in 2006, Canonical has a "no goats" policy.
[09:12] <vila> oooops, I wasn't aware of this policy, damn
[09:12] <mneptok> maybe they'll change it now that both Keybuk and i are gone.
[09:14] <vila> sounds more like it ;)
[09:19] <poolie> hi vila
[09:20] <vila> poolie: hey !
[09:20] <poolie> thanks for your mail
[09:20] <vila> hmm, which one ?
[09:20] <poolie> 'wheezy inhaling'
[09:20] <poolie> nice title
[09:20] <mrevell> Morning
[09:20] <vila> Oh, you already got it, cool
[09:20] <poolie> thanks for putting a summary at the top too
[09:20] <vila> hehe
[09:20] <poolie> it would have been a wee bit better if the summary had said what the bottom line was
[09:21] <poolie> just as an idea for next time
[09:21] <poolie> ie "we're all done"
[09:21] <vila> haha, of course ;)
[09:21] <poolie> or we're not?
[09:21] <vila> well, yeah, we're done for wheezy
[09:21] <poolie> i wasn't totally clear
[09:21] <poolie> ok
[09:22] <vila> we didn't significantly regress on the number of failures, so it's a nice result
[09:22] <vila> poolie: I also submitted the script I used to analyze the logs
[09:23] <vila> well, almost all logs, 28 with one being 5GB uncompressed and one being 300M compressed
[09:24] <vila> I couldn't uncompress the 300M one but both of them contain mostly 'still active' spam so hopefully nothing valuable was lost
[09:24] <vila> well, not lost, just not usable so far
[09:26] <vila> now I can resume my work on making the p-i more robust and mail the list about that and some related ideas (working on it right now)
[09:36] <vila> poolie: wgrant also mentioned one branch (can't remember which) still using rich-root-pack instead of 2a
[09:37] <vila> poolie: the branch is probably broken on lp at this point after a failed attempt to stack
[09:37] <poolie> k
[09:42] <wgrant> poolie, vila: xserver-xorg-video-voodoo
[09:42] <vila> right !
[09:43] <vila> wgrant: can you file a bug for it ?
[09:43] <wgrant> I'm not entirely sure if it's a bug.
[09:44] <vila> well, leaving a broken branch on lp is one ;)
[09:44] <lifeless> we need to upgrad them all
[09:45] <wgrant> vila: Which logs from jubany are useful?
[09:45] <wgrant> /srv/package-import.canonical.com/new/logs, but do we also want /srv/package-import.canonical.com/new's old logs?
[09:46] <vila> ECONTEXT
[09:47] <wgrant> vila: I filed an RT asking for them to be synced to devpad so launchpadders can see them.
[09:47] <wgrant> But I have been told that /srv/package-import.canonical.com/new has some logs, and asked if we want them too.
[09:47] <vila> wgrant: I haven't looked into the new/logs ones, the ones in new itself are related to the controller
[09:47] <vila> yup
[09:48] <wgrant> OK, thanks.
[09:48] <vila> the ones in new/logs are by package
[09:48] <wgrant> Right.
[12:59] <pfarrell> hello! I'm using bzr-svn so that I can use bzr with my group's svn repository
[12:59] <pfarrell> lately when I try to bzr up, I get --
[13:00] <pfarrell> bzr: ERROR: checksum mismatch: '883d0c2e655f3ad55a1c069193827fff' != 'eb7cf436745e9c4265dcfad3365a8552' in trunk:15475
[13:00] <pfarrell> any ideas what on earth it could be, or how I could go about debugging it?
[13:31] <jelmer> pfarrell: what version of bzr-svn are you using?
[13:31] <pfarrell> the one in ubuntu maverick (1.0.3)
[13:32] <jelmer> pfarrell: there's an open bug report about that issue
[13:32] <jelmer> including a workaround, but that requires upgrading to a newer version of bzr-svn
[13:32] <pfarrell> apologies, I know I should have looked; I was lazy
[13:33] <pfarrell> ok .. I guess I'll just use svn for now
[13:34] <maxb> You could try the ~bzr PPA for newer versions
[13:54] <maxb> james_w: Hello, I was hoping to ask you a question about bzr-builddeb. The following revision seems bogus: http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/482 - given that 2.6 is tagged and uploaded to Debian and Ubuntu.
[13:54] <james_w> it does
[13:56] <maxb> Are you fine with simply reverting that, then?
[13:58] <james_w> maxb, sure
[14:23] <vila> james_w, maxb: As long as the info.py get updated too :)
[14:32]  * maxb lols at vila's subject line to u-d-d@
[14:37] <vila> :)
[14:53] <james_w> vila, nice investigations, thanks
[14:54] <vila> james_w: thanks for leaving us a robust tool to play with ;)
[14:55] <james_w> vila, you said that spm restarted the importer at one point, why was that?
[14:55] <vila> didn't I mentioned the bug # ?
[14:56] <vila> bug #719196
[14:57] <vila> james_w: at least that's what I suspect so far
[14:57] <james_w> ah
[14:57] <vila> james_w: a bit surprising but race conditions... are so shy sometimes
[14:57] <james_w> I missed the connection
[14:59] <vila> ha, damn, I didn't mention the log excerpt, just a sec
[15:00] <vila> 2011-02-13 19:56:59,671 - __main__ - CRITICAL - Driver hit database is locked
[15:00] <elmo> I'm going to ask a random paramiko question here, because I suspect someone will know.. exec_command() appears to be 'ssh foo.example.com bar', what's the equivalent of 'echo bar | ssh foo.example.com' in paramiko?
[15:03] <vila> elmo: bzr use exce_command() :-}
[15:07] <vila> elmo: I'm not even sure I understand how 'echo bar | ssh foo.example.com' would work in paramiko speak... this reminds me of the infamous XXX in bzrlib.tests.test_transport.TestSSHConnections...
[15:08] <vila> i.e. you need to do the plumbing yourself around the paramiko channel
[15:09] <elmo> vila: yeah, I'm trying that now
[15:09] <elmo> vila: thanks
[15:11] <vila> elmo: try again later with spiv, I only slightly changed this test
[15:12] <vila> (but banged my head on paramiko doing so...)
[15:12] <vila> james_w: so the exception is stringified and traceback lost but, as said in the bug, I suspect a race condition
[15:13] <vila> meh, a race condition when spawning the imports
[15:14] <james_w> vila, sounds reasonable
[15:14] <james_w> vila, we should probably change it to not lose the traceback too
[15:14] <vila> that too...
[15:15] <vila> james_w: bug update
[15:15] <vila> d
[17:59] <thrope> i just installed bazaar windows standard installer on windows 2008 server but it doesnt work well
[17:59] <thrope> it is impossibly slow
[17:59] <thrope> (~1min to open bzr explorer)
[17:59] <thrope> about 5 mins after log in the explorer extensions show up
[17:59] <thrope> but dont do anything
[18:00] <thrope> oh no they do - it just takes 2-3minutes for the checkout box to pop up
[18:00] <thrope> is there anything I can do about this?
[18:01] <vila> thrope: since this does not really match feedback from other windows users, you probably have a setup problem...
[18:01] <thrope> when I select checkout from the menu I see a tbzrcommand.exe process start with about 2MB
[18:01] <thrope> the memory usage slowly grows to about 20
[18:01] <thrope> then the window pops up
[18:01] <vila> thrope: it could be a anti-virus being overzealous, I'm not a windows expert though
[18:02] <thrope> but it is not even writing any files yet - this is just opening the dialog
[18:02] <vila> ha, I'm not sure the usual windows suspects are around, you'd better file a bug report against tbzr
[18:03] <vila> thrope: https://launchpad.net/tortoisebzr/+filebug
[18:03] <thrope> ok thanks
[18:03] <vila> thrope: be sure to mention the version you're using and search around for a .bzr.log file
[18:04] <vila> thrope: 'bzr version' should tell you where to find it
[21:35] <poolie> stefanlsd, hi?
[21:36] <thumper> hi
[21:36] <thumper> I have a custom virtual transport
[21:36] <poolie> hi jam
[21:36] <poolie> hi thumper
[21:36] <thumper> which is supposed to implement all the public transport methods
[21:36] <jam> morning poolie
[21:36] <thumper> but I have a feeling it doesn't
[21:37] <thumper> and when I tried to do bzr info -v over the transport, it barfed at me
[21:37] <thumper> how can I test my virtual transport to make sure it does implement all the expected methods?
[21:37] <poolie> do you get a traceback?
[21:37] <poolie> running it through per_transport tests ought to do that
[21:37] <poolie> however it's possible info requires something the tests treat as optional, or something like that
[21:37] <poolie> which would be a bug
[21:40] <jam> thumper: if you are registering your transport, you can add a function in the module, and then the per-transport permutation tests will run against it
[21:40] <jam> let me check a sec
[21:40] <thumper> jam: my transport gets registered as part of a different plugin
[21:40] <thumper> jam: it operates very much like the launchpad virtual transports
[21:40] <jam> thumper: get_test_permutations()
[21:41] <jam> thumper: the per-transport tests specifically look at what transports are registered
[21:41] <jam> check what module they are comming from
[21:41] <jam> and look for a get_test_permutations() function
[21:41] <jam> if it is present, then they will run the per_transport tests against the result
[21:41] <thumper> the transport is registered at the start of a smart server process and unregistered at the end
[21:42] <thumper> poolie: ok, thanks, I'll look into that too
[21:42] <poolie> thumper, have you got a traceback?
[21:42] <thumper> in .bzr.log yes
[21:42] <jam> thumper: so... register it globally under an unaccessible url
[21:42] <jam> just a thought
[21:42] <poolie> that should make it obvious...
[21:42] <thumper> jam: can't really, as it needs to be constructed with a server object
[21:42] <jam> thumper: that is what the test permutations is about
[21:43] <jam> setting up a server
[21:43] <jam> so that the tests can run against it
[21:43] <jam> considering that is what happens for sftp, ftp, bzr+ssh, etc
[21:43] <jam> you could also just monkeypatch "bzrlib.transport._get_transport_modules()"
[21:43] <jam> it just returns a list
[21:44] <jam> and already has 2 modules hard-coded in it
[21:44] <thumper> actually, it looks like me
[21:44]  * thumper looks sheepish
[21:44]  * thumper hacks
[21:46] <lifeless> thumper: the memory-1234: urls have the same issue and constraints for testing pretty much
[21:46] <lifeless> thumper: as jam and poolie are describing
[21:47] <thumper> yep... thanks
[21:47] <jam> lifeless: thanks, I was looking at StubSftpServer, but MemoryServer is much more straightforward
[21:48] <jam> to register a new server, tell the test code what address to use to access it, and shut it down again
[21:50] <thumper> if I have a chrooted transport, are any clones of that also chrooted?
[21:50] <thumper> and are they chrooted to the new path?
[21:50] <thumper> I'd expect so, but just checking
[21:51] <thumper> abentley: hi, did my bug last night make sense?
[21:52] <abentley> thumper, I only glanced at at, but it seemed reasonable.
[21:52] <abentley> s/at at/at it/
[21:52] <thumper> abentley: ok, cool
[21:52] <thumper> abentley: if you have any questions, I'd be happy to help
[21:53] <thumper> abentley: also... I was working in a shared repo, with trees
[21:53] <thumper> abentley: and reconfigure-pipe worked
[21:53] <thumper> but when I tried to push
[21:53] <thumper> my append path policy screwed up the push to launchpad
[21:53] <abentley> thumper, the idea is that you have uncommitted changes in a shelf, you delete another shelf, that switches you into the first shelf, but you don't get the uncommitted changes?
[21:53] <thumper> as it was now in .bzr/pipes/whatever
[21:53] <abentley> sorry, let me try again.
[21:54] <thumper> s/shelf/pipe/ then yes
[21:54] <abentley> thumper, yes, that's the sort of mistake I can imagine making.
[21:55] <abentley> thumper, yes, reconfigure-pipe isn't really suitable for Launchpad work.
[21:55] <thumper> it wasn't launchpad work
[21:55] <thumper> but the project is hosted on LP
[21:55] <abentley> thumper, that's what I mean.
[21:55] <thumper> hmm...
[21:55] <abentley> bad for launchpad-hosted work.
[21:56] <thumper> yeah
[21:57] <abentley> thumper, it's a basic model issue, because the location of the branch changes when you do reconfigure-pipeline.
[21:58] <thumper> abentley: yeah... I briefly was thinking of a way around it, but I gave up
[21:58] <abentley> thumper, we may need a different way of doing that sort of configuration.  For example, if we could append the nick instead of the path.
[21:58]  * thumper nods
[21:59] <jam> thumper: cloning a chrooted transport is supposed to keep you in the chroot. Otherwise it wouldn't be much good :)
[22:00] <abentley> thumper, it's also possible that bzr-colo has solved that (but I doubt it).  I've been meaning to switch to using bzr-colo for bzr-pipeline.
[22:00] <thumper> jam: what I was meaning... was if I had a chrooted_transport which wraps (/local/path), if I have t.clone('subpath'), is the resulting transport now chrooted inside /local/path/subpath ?
[22:00] <jam> thumper: no, it is chrooted inside /local/path, AFAIK
[22:01] <thumper> hmm...
[22:01] <lifeless> jam is correct
[22:01] <lifeless> the chroot is a decorated transport, you can clone down and up within that transport as much as you want, but not up above it
[22:01] <thumper> I think that is OK for my current use
[22:02] <thumper> we have our bzr server hosting project almost ready to roll out
[22:02] <thumper> we use a lot of code from LP, ripped and hacked to provide SSH key authentication against SSH key values in our DB
[22:03] <thumper> but we just have simple file paths with shared repos for each user and project
[22:03] <thumper> the primary use case is for the local polytechnic (technical college)
[22:04] <thumper> privacy is there by default for projects and users
[22:04] <thumper> to stop copying :-)
[22:05] <lifeless> poolie: jam: bug 437003 is possibly worth doing fairly soon
[22:05] <lifeless> it caused /lots/ of confusion in the u1 project today
[22:06] <lifeless> its a very worrying error when it occurs
[22:06] <jam> well, until you search for a bug with that 'missing inventories' string, and see that you just 'bzr pack'...
[22:06] <lifeless> jam: they didn't do that
[22:07] <jam> I would expect when getting a failure for them to investigate, and we can tell them right away what's up, if they just sit and privately worry, there isn't much we can do for any bug that we have
[22:08] <jam> I'm not saying it isn't worth escalating that particular bug
[22:09] <jam> but saying it should become Critical for something with a known workaround that happens rarely doesn't seem quite right
[22:09] <lifeless> mmm, I'm not saying it should be critical
[22:10] <lifeless> I'm just saying that it cost a couple of man hours today
[22:10] <lifeless> and that its a very worrying error to encounter
[22:18] <poolie> definitely a worrying error
[22:48] <jam> time for me to EOD, I'll try to be back online later
[23:36] <poolie> hi spiv?
[23:41] <spiv> Hi poolie
[23:44] <poolie> how are you?
[23:47] <spiv> Older today!
[23:47] <spiv> Hmm, and with intermittent ADSL for some reason.
[23:47] <poolie> :) congratulations
[23:47] <poolie> nice to see the arrow of time is still functioning correctly
[23:47] <spiv> It keeps losing line sync, but I don't recall V grabbing at those cables recently...
[23:48]  * spiv randomly twiddles a few connections and crosses his fingers
[23:53] <poolie> i'm moving the kanbans to be on people.c.c. so they can update more frequently
[23:53] <poolie> do you have a preference about having them public vs having them include private bugs?
[23:53] <poolie> i'm slightly inclined to the former
[23:53] <spiv> Me too
[23:54] <spiv> We don't have enough private bugs to make including them in the kanban worth it, I think.


[14:01] <smoser> harlowja, the errors... you really have no 'ip' command ?
[14:02] <smoser> you need to fix that nonsense.
[14:02] <smoser> silly paths on redhat
[16:47] <smoser> harlowja, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/307200
[16:47] <smoser> that fixes some of those gist failures i think
[17:39] <smoser> harlowja, ping
[19:38] <smoser> magicalChicken, around ?
[20:01] <harlowja> smoser sorry, got up late and just got in :-P
[20:01] <harlowja> us cali people, lol
[20:02] <harlowja> smoser so there is an ip command
[20:02] <harlowja> but something maybe just isn't mocked right
[20:02] <smoser> hm.
[20:03] <smoser> can you help me get a cent6 and cent7 environment ?
[20:03] <smoser> would like to know how to do that.
[20:15] <magicalChicken> smoser: i have a work in progress of my branch that adds that
[20:15] <smoser> magicalChicken, embarrasing question
[20:15] <smoser> i was looking at your doc branch
[20:15] <smoser> how do i build doc
[20:16] <smoser> https://public.etherpad-mozilla.org/p/cloud-init-centos-unittest
[20:16] <magicalChicken> Oh haha, its 'sphinx-build docs/rtd /tmp/docs'
[20:22] <magicalChicken> Oh, I don't have a setup for lxd based centos environment yet, just got curtin vmtests. I can look into that though tonight
[20:23] <smoser> magicalChicken, you want to add : http://paste.ubuntu.com/23252743/
[20:25] <magicalChicken> Sure, I'll get that added in
[20:26] <magicalChicken> Right now we're using the default template too, not the one for read the docs, I can add that into the repo too, but I think when we build the docs there it will use it by default
[20:27] <magicalChicken> I've gotta relocate to go get my laptop, I'm on a lab machine right now. I'll get that merged in in 15
[20:30] <harlowja> virtualbox :-P
[20:31] <harlowja> smoser let me run your branch on cent7
[20:31] <harlowja> see what happens
[20:32] <smoser> harlowja, https://public.etherpad-mozilla.org/p/cloud-init-centos-unittest
[20:32] <smoser> teach me
[20:32] <smoser> ssh<EMAIL_ADDRESS>[20:33] <harlowja> $ git clone -b open-nebula-no-ip https://git.launchpad.net/~smoser/cloud-init cloud-test
[20:33] <harlowja> Cloning into 'cloud-test'...
[20:33] <harlowja> remote: Counting objects: 22313, done.
[20:33] <harlowja> remote: Compressing objects: 100% (7809/7809), done.
[20:33] <harlowja> Receiving objects:  28% (6292/22313), 2.47 MiB | 12.00 KiB/s
[20:33] <harlowja> smoser  are the tubes broken over there, lol
[20:33] <harlowja> down to 8kb/s
[20:33] <harlowja> lol
[20:33] <harlowja> restarted, seems better
[20:33] <harlowja> maybe a tube was broken somewhere
[21:04] <magicalChicken> smoser: I just got the tox env for docs added in and pushed to the repo
[21:04] <smoser> magicalChicken, ok. thanks.
[21:04] <magicalChicken> I noticed though, in tox its trying to highlight everything as python
[21:04] <magicalChicken> it wasn't doing that outside of tox
[21:04] <magicalChicken> I need to figure out why real quick
[21:05] <magicalChicken> i think its py2 sphinx vs py3 sphinx
[21:07] <smoser> hm.
[21:07] <smoser> ok.
[21:07] <smoser> got to run now
[21:08] <magicalChicken> I'll get that fixed and pushed tonight
[22:08] <harlowja> smoser  https://gist.github.com/harlowja/62315edad713304076f35ff40ac9c4f1
[22:08] <harlowja> so 1 fail i think still
[22:09] <harlowja> *that's using https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/307200
[22:09] <harlowja> using/running
[22:25] <harlowja> one more mocking fix probably addresses that


[08:27] <Forza> Hello
[08:28] <Forza> I have an issue with 20.04lts. During reboot systemd tries to unmount the filesystem used by targetclid before stopping targetclid.
[08:28] <Forza> Then it doesn't try to unmount the filesystem again before rebooting/halting which leads to corruption
[18:21] <MIF> Ok i have something talking up aton of space
[18:21] <MIF> but I just can't find it
[18:21] <MIF> ncdu dose not give me anything that helpful
[18:23] <MIF> does anyone have any tips, or other things I can try?
[18:50] <rfm> MIF, you are running ncdu as root?  otherwise it might not see into dirs you can't read
[18:51] <MIF> it is as root
[18:51] <MIF> the only think I could find was the sys and kernal log
[18:51] <MIF> the only think I could find was the sys and kernal logs
[18:52] <MIF> but still my disk usesage is very high
[18:55] <rfm> MIF, you may have a unlinked-but-still-open file.  These can be a pain to run down.
[18:55] <MIF> how do I check?
[18:56] <rfm> MIF, 'lsof { grep '(deleted)' " will show them
[18:57] <rfm> MIF, hmm, just tried it, lsof shows more useful info than it used to when I last had this problem years ago
[18:57] <MIF> there is alot here
[18:58] <MIF> https://pastebin.com/RvUDUbSY
[18:59] <MIF> https://pastebin.com/raw/RvUDUbSY
[18:59] <MIF> ^that view is better
[19:02] <rfm> MIF, those fail2ban logs are huge (actually suspiciously so, I wonder if lsof is misreporting)
[19:05] <rfm> MIF, no idea why f2b is keeping them open.  You could try stopping f2b (which will close the files held open by pid 1063) and see if the space comes back
[19:09] <MIF> ok
[19:10] <rfm> MIF, hmm, it's just the same one file (inode 1313619) open many times, not multiple files at least
[19:10] <MIF> yep that worked
[19:10] <MIF> back to 37%
[19:10] <MIF> thanks rfm
[19:12] <rfm> MIF, this actually looks like a bug in fail2ban, might look into reporting it.  if it comes back, maybe look into setting up a periodic restart of f2b
[19:25] <MIF> ok
[19:25] <rfm> MIF, might not be a but in fail2ban, this situation would arise if somebody saw the big log and rm'ed it but didn't restart fail2ban (could even be a log rotation service if you have one)
[19:25] <MIF> that is what I did
[19:25] <MIF> I rm'd the log file
[19:25] <MIF> and did not restart fail2ban
[19:27] <rfm> MIF, ah! so all you need to do is remember to restart next time (might want to check into why f2b is writing so much to its log, perhaps you're getting really hammered by somebody trying to break in?)
[19:27] <MIF> no, I think I have it set to debug


[06:23] <elmo> anyone with cdimage access around?
[07:19] <seb128> that sync ^ has no lp reference but the ffe is bug #1379344
[07:19] <ubot2> bug 1379344 in glibmm2.4 (Ubuntu) "[FFe] Update glibmm to 2.42" [Medium,Triaged] https://launchpad.net/bugs/1379344
[07:19] <seb128> it makes the binding be on the same serie as the lib and fix the current ftbfs
[10:07] <cjwatson> stgraber: please can you make sure to run the test suite before committing to cdimage?
[10:07] <cjwatson> fixing it up now ...
[10:55] <stgraber> cjwatson: oops, sorry, I always forget that config changes also break the testsuite...
[10:57] <stgraber> slangasek: so cjwatson reported bug 1379274 as a regression from the switch to python3 and switched import-images back to python2 which hit the bug again and filled up nusakan's disk. I've now added a test and pushed a fix for unicode handling in the removal list for python2.
[10:57] <ubot2> bug 1379274 in Ubuntu system image "import-images fails under Python 3 when there are multiple images and at least one lacks a base" [Undecided,New] https://launchpad.net/bugs/1379274
[10:58] <stgraber> slangasek: so for hte time being, we'll keep things running under python2 and I'll look into cjwatson's bug later, then do proper testing of python3 before we consider switching produciton to python3
[11:07] <stgraber> system-image is back to normal, crontab entry re-enabled
[11:11] <cjwatson> stgraber: thanks
[11:12] <cjwatson> stgraber: would appreciate review of https://code.launchpad.net/~cjwatson/ubuntu-system-image/cdimage-custom/+merge/237942 if you get a chance - fairly urgent
[11:13] <cjwatson> rationale's near the end of the linked (unfortunately private) bug
[11:17] <stgraber> cjwatson: merged and deployed
[11:19] <cjwatson> yay thanks
[11:19] <cjwatson> glad I understood the model properly
[11:20] <cjwatson> so we'll just need to add an extra cdimage-custom line to etc/config after deploying livecd-rootfs
[11:21] <stgraber> more like changing the existing custom line to use the cdimage-custom generator instead of the http one, but yeah
[11:22] <stgraber> reminds me I really need to split the generators out as separate files, generators.py is starting to be pretty messy :)
[11:23] <cjwatson> right yeah
[11:24] <cjwatson> I guess thinking about it we can safely land livecd-rootfs without that
[11:24] <cjwatson> because nothing happens to the actual build until etc/config is changed
[11:24] <cjwatson> oh no, that would drop those click packages from rootfs into a black hole
[11:25] <stgraber> yeah, I think we'll need to be pretty careful, stop the system-image cron, land cdimage, build a new image, update system-image's config, run import-images by hand to confirm all is well, then turn cron back on
[11:26] <cjwatson> land livecd-rootfs, but yeah
[11:26] <cjwatson> I deployed the cdimage code already, since it should be a no-op if livecd-rootfs hasn't generated custom.tar.gz
[11:27] <stgraber> ah right
[11:27] <stgraber> an alternative would be to change livecd-rootfs to first both install the clicks in the rootfs and generate custom.tar.gz with the same clicks. Then we can land that, switch system-image, test everything and then land a second livecd-rootfs which stops including the clicks in the rootfs
[11:28] <stgraber> that's all based on the assumption that click doesn't freak out if something is both in the system path and in /custom
[11:28] <cjwatson> shouldn't any more following the click-apparmor changes
[11:28] <cjwatson> ok, I'll follow up on https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905
[12:49] <stgraber> cjwatson: are you the one holding the vim lock on etc/config ?
[13:00] <cjwatson> stgraber: oh sorry, dropped
[13:01] <stgraber> thanks
[14:42] <jamespage> the neutron upload I did a few minutes ago resolves a blocking issue in our RC testing; however it does pull a new package into main (ipset) - MIR raised and apologies - missed that delta on the rc1
[14:43] <stgraber> cjwatson, ogra_, slangasek: so who just switched system-image back to python3 again? :)
[14:43] <stgraber> I'm getting tracebacks in my e-mails
[14:44] <ogra_> stgraber, i didnt touch the code at all
[14:44] <ogra_> (i ran import-images with python and python3 prefix manually this morning thouh ... to get the images out ... are you sure these mails are recent ?)
[14:45] <stgraber> ogra_: yeah, they're pretty recent and I see that someone re-applied slangasek's change manually in /srv/system-image.ubuntu.com
[14:45] <stgraber> so system-image is currently broken
[14:45] <ogra_> ouch
[14:46] <ogra_> i know lool just built an image, but i think he only touched crontab
[14:46] <cjwatson> I didn't touch it
[14:46] <lool> I've only touched crontab
[14:46] <cjwatson> you sure it wasn't a merge conflict thing
[14:46] <cjwatson> ?
[14:46] <lool> and ran an rtm image build
[14:46] <lool> I didn't bzr anything
[14:48] <stgraber> I'm having doubts now :) I'm pretty sure I did uncommit+revert before pulling the updated code but maybe I forgot the revert and we've somehow been lucky not to hit the broken python3 codepath until now (because the past 20 or so runs were successful, it just started failing again about 20min ago)
[14:49] <stgraber> anyway, just dropped all the local delta so the next run should succeed again
[23:02] <cjwatson> (that's a binary sync; I took care because perl can easily make the archive grumpy if you end up with build skew)
[23:02] <cjwatson> slangasek,infinity: would you have a minute to review debian-installer so that the new kernel can get in?  there's one ppc64el-specific change in there too
[23:03] <slangasek> yes, looking
[23:06] <infinity> cjwatson: oh, thanks for that, I got distracted.
[23:07] <infinity> cjwatson: Are minicmd/reboot consistent with other arches?
[23:08] <infinity> cjwatson: Oh, I guess we cargo-culted this from kfreebsd, which has an entirely different module selection.
[23:09] <infinity> But minicmd is there, at least.
[23:09] <infinity> slangasek: You still reviewing that, or okay for me to let it in?
[23:09] <slangasek> infinity: no, and no!
[23:09] <infinity> That answers that.
[23:10] <infinity> ;)
[23:13] <slangasek> yes, it's always nice to see the queuebot accepting a botch sync
[23:24] <cjwatson> yeah there isn't really a perfect analogue elsewhere but I guess kfreebsd is closest right now