[00:11] <perrito666> its the checker that does reflective stuff, ill try
[00:18] <alexisb> axw, made an update to the TB call, let me know if that time sitll works
[00:26]  * perrito666 loves git squash
[00:34] <redir> squash perito666 +1
[01:00] <perrito666> wallyworld: did you see https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70  ?
[01:01] <wallyworld> perrito666: one sec, otp
[01:02] <axw> alexisb: sorry went to take charlotte to school. that time is fine for me
[01:06] <redir> see you tomorrow juju-dev
[01:18] <perrito666> wallyworld: ping me when you are !otp
[01:19] <wallyworld> perrito666: yo
[01:20] <perrito666> wallyworld: yo?
[01:21] <wallyworld> perrito666: a colloquial term for "hello" or "i'm here"
[01:21] <perrito666> ah, also means I in spanish
[01:21] <perrito666> wallyworld:  the link I passed, did you see that before asking for ernonnilless? (or you meanth something else?)
[01:22] <wallyworld> didn't see the link
[01:23] <wallyworld> perrito666: which link?
[01:23] <perrito666> https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70
[01:24] <wallyworld> perrito666: oh, didn't see that
[01:24]  * perrito666 clicks fixed
[01:24] <wallyworld> we want jc.ErrorIsNil though right?
[01:24] <perrito666> we do, actually
[01:24] <perrito666> I wonder I used isnil
[01:25] <wallyworld> errorisnil covers some corner cases
[01:25] <perrito666> let me try with errorisnil
[01:26] <perrito666> wallyworld: the code got dizzy with everything we tried and I forgot to errorisnil that
[01:26] <wallyworld> np
[01:26] <perrito666> ... value *params.Error = <nil>
[01:26] <perrito666> ... value of (*params.Error) is nil, but a typed nil
[01:26] <perrito666> meh
[01:26] <perrito666> that is a fine example of a useless error message
[01:28] <perrito666> ah its the apiserver
[01:29] <perrito666> its a params.Error
[01:36] <perrito666> well fine people, I need sleep
[01:36] <perrito666> see you all tomorrow
[02:13] <thumper> fuck
[02:13] <thumper> fuckity fuck
[02:13]  * thumper composes email...
[02:20] <thumper> wallyworld, menn0: see email for WTF moment
[02:20] <menn0> looking
[02:20] <wallyworld> ok
[02:23] <wallyworld> thumper: +1 from me on fixing
[02:23] <thumper> wallyworld: I may quickly whip up a branch that cleans this up
[02:24] <thumper> the idea of a unique index on something that can be empty is werid
[02:24] <thumper> wierd
[02:24] <thumper> weird
[02:24] <thumper> ?
[02:24] <thumper> one of those
[02:25] <menn0> thumper: isn't the issue though that the providerid isn't necessarily known in this case?
[02:25] <thumper> does sparse mean ignore empty?
[02:25] <menn0> thumper: nil values aren't stored in sparse indexes
[02:25] <thumper> ok
[02:25] <menn0> thumper: the index doesn't include documents where the indexed value is nil
[02:27] <menn0> thumper, wallyworld: I don't know what the behaviour is when you have a compound sparse index
[02:28] <menn0> docs are here: https://docs.mongodb.org/manual/core/index-sparse/#sparse-compound-indexes
[02:28] <menn0> but I don't know what they mean by "ascending/descending index keys"
[02:29] <thumper> Sparse compound indexes that only contain ascending/descending index keys will index a document as long as the document contains at least one of the keys.
[02:29] <natefinch> axw: that bug you linked to in the mail about os.Exit in a test.... that test should just return unless you somehow have JUJU_WANT_HELPER_PROCESS set in the environment
[02:29] <thumper> yeah
[02:29] <axw> natefinch: it does not.
[02:29] <axw> natefinch: it calls Main, and Main is calling os.Exit
[02:29] <axw> natefinch: Main should return rc, and main should call os.Exit
[02:29] <axw> which is what I'm changing it to do now
[02:30] <natefinch> axw: I explicitly changed main *not* to os.exit
[02:30] <natefinch> axw: maybe that change got overridden somehow
[02:30] <natefinch> er Main that is
[02:31] <axw> natefinch: blame says the line is unchanged since 2014 *shrug*
[02:31] <thumper> menn0: perhaps we should be doing the provider unique check in a different way
[02:31] <natefinch> axw: weird, maybe I reverted it by accident..
[02:31] <menn0> thumper: I think we should.... I'm replying to the thread now
[02:31] <thumper> thanks
[02:33] <mup> Bug #1578456 opened: cmd/juju/commands: not all tests are being run <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1578456>
[02:34] <natefinch> axw: you're right, I don't see it. That's so weird.
[02:35] <natefinch> axw: oh crap, here it is: https://github.com/juju/juju/pull/5250
[02:35] <axw> natefinch: heh :)
[02:36] <natefinch> axw: mind if I land mine? it has some better testing in it, too
[02:36] <axw> natefinch: fine with me, but I think you'll have some ssh/scp tests to fix too
[02:36] <axw> natefinch: I've just run with my changes, and there's some test failures
[02:36] <natefinch> axw: blech
[02:37] <axw> natefinch: if you like I can press on, and you can land over the top
[02:37] <axw> should be mostly the same anyway, apart from your other changes
[02:37] <natefinch> axw: fine by me
[02:38] <natefinch> axw: sorry to make you waste time debugging that.
[02:39] <axw> natefinch: no worries, didn't take long to track down. I was mostly concerned about the tests being skipped, but thankfully there's just a couple of small ones broken
[02:40] <axw> ugh, my writing has become atrocious, constantly missing words out
[02:40] <thumper> axw: who needs words
[02:40] <thumper> you know...
[02:40] <thumper> thingy
[02:40]  * axw beams thoughts
[02:41] <thumper> menn0: bugger
[02:41] <thumper> menn0: migration fails...
[02:41] <thumper> for spaces with a provider set
[02:41] <thumper> 	github.com/juju/juju/state/spaces.go:141: ProviderId "provider" not unique
[02:41] <thumper> so I'm not sure it is actually working...
[02:42] <menn0> thumper: nuts
[02:42]  * thumper pokes and adds a bucket of logging
[02:44] <thumper> ha
[02:44] <thumper> it isn't the import
[02:44] <thumper> but the factory creation
[02:44] <thumper> WTF
[02:48] <thumper> menn0: ok, need help
[02:48] <thumper> got a minute?
[02:48] <thumper> I *think* what I'm doing should work
[02:48] <thumper> but it isn't
[02:49] <menn0> thumper: 1:1?
[02:49] <thumper> ack
[03:04] <axw> spontaneous shutdown is one way to get me to update my kernel
[03:06] <natefinch> lol
[03:09] <natefinch> what is supposed to happen if you juju deploy trusty/ubuntu --series xenial? :/
[03:13] <thumper> menn0: where is the manifold for the apiserver
[03:13] <thumper> ?
[03:13] <natefinch> why do we even have a --series on deploy?  isn't that what the foo/bar format is for?
[03:14] <menn0> thumper: that's one fo the things that jesse was working on but I don't think it's done yet
[03:14] <thumper> oh fark...
[03:15] <menn0> thumper: I believe he got it mostly working but there were issues, or he had to wait for some other stuff to land or something
[03:15]  * thumper nods
[03:15] <thumper> we probably want that landed very soon
[03:15] <thumper> definitely pre 2.0
[03:16]  * menn0 checks jesse's repo
[03:17] <menn0> thumper: here it is: https://github.com/waigani/juju/tree/MADE-apiserver
[03:18] <axw> natefinch: --series is for multi-series charms. we're moving away from "ubuntu/trusty", to plain old "ubuntu"
[03:18] <axw> natefinch: and IIRC you should be able to force charms to series of the same OS by using --series, wallyworld will remember better tho
[03:18] <menn0> thumper: I can take a look at that once this SSH stuff is done
[03:19] <thumper> menn0: ok, that's be good
[03:19] <wallyworld> axw: --series and --force if needed
[03:19] <natefinch> axw: it just means we have two different ways of specifying the same thing... which is confusing and in this case, causing a bug
[03:19] <menn0> thumper: it's migrations related anyway
[03:19] <wallyworld> eg if a charn declares it supports trusty and we want to install on xenial
[03:19] <thumper> menn0: it is
[03:19] <natefinch> juju deploy precise/ubuntu will deploy ubuntu on xenial
[03:20] <axw> menn0: how many changes to you have in cmd/juju/commands/scp.go? I'm looking at moving off JujuConnSuite, and using a mock API
[03:20] <axw> menn0: don't want to make your life difficult tho
[03:20] <wallyworld> the expectation is those series specific urls are not going to be necessary, but in the interim, that charm should go to precise
[03:21] <menn0> axw: i've made extensive changes to the tests so it would be good if you waited
[03:21] <axw> menn0: okey dokey
[03:21] <menn0> axw: I'm hoping to be done with it today
[03:21] <natefinch> I can fix that, of course, but then we still have the case of juju deploy precise/ubuntu --series xenial.... I guess at that point I just have to error out, since I don't actually know what the user wants
[03:21] <axw> menn0: can you please test them in isolation, because I found TestSCPCommand fails atm if you run it with others
[03:21] <axw> menn0: actually I can fix that later if need be
[03:21] <axw> never mind
[03:21] <wallyworld> natefinch: no, in that case you require --force
[03:22] <wallyworld> and yeah, error if --force is not provided
[03:22] <natefinch> wallyworld: well, asking the charmstore for precise/ubuntu returns you the multi-series ubuntu charm
[03:22] <wallyworld> it does yes
[03:22] <natefinch> wallyworld: which can deploy to xenial just fine
[03:23] <wallyworld> those series/charm urls are for backwards compatibility
[03:23] <natefinch> ...so right now, it does
[03:23] <wallyworld> natefinch: but the user has specified precise in the url - it they want --series xenial we need --force
[03:23] <menn0> axw: by "in isolation" do you mean just run the individual suites?
[03:24] <wallyworld> if they specify the charm without series in url, that's different
[03:24] <axw> menn0: actually I had arse about, so forget I said anything :)   I'm finding that the scp tests fail because the output includes identity files from the fake juju home, and that's not expected in the output. running TestSCPCommand passes if I run it by itself
[03:24] <axw> menn0: so it seems to not be getting a clean fake home
[03:25] <menn0> axw: hmmm... I haven't noticed that
[03:25] <axw> menn0: I'll fix that and forget about changing scp for now
[03:25] <axw> menn0: well, cmd/juju/commands doesn't run all the tests atm. have you changed that in your branch?
[03:25] <axw> menn0: i.e. because of the bug I sent to the list
[03:25] <menn0> axw: no I haven't changed that, just the ssh, scp and debug-hooks tests and implementations
[03:26] <axw> ok
[03:26] <menn0> axw: yeah I saw that
[03:26] <menn0> axw: but i've been running the individual tests/suites using -gocheck.f
[03:26] <menn0> axw: did you fix that problem already?
[03:26] <axw> menn0: nope, still looking into it
[03:27] <axw> menn0: I'll fix that and come back to removing JujuConnSuite after you land your changes
[03:27] <menn0> axw: ok thanks
[03:36] <menn0> axw: one wrinkle, I can't land this stuff until master is unblocked
[03:36] <axw> menn0: it's cool, no hurry
[05:14] <menn0> axw: if someone is use juju scp/ssh to an arbitrary hostname or address, do you think the users personal known_hosts should be used, or just /dev/null ?
[05:14] <menn0> axw: e.g. "juju ssh <IP_ADDRESS>", as opposed to "juju ssh 3"
[09:04] <anastasiamac> fwereade: o/
[09:05] <anastasiamac> fwereade: lts PR was backport to 1.25... should we forward sugestions to master once the PR is ready?
[09:16] <fwereade> dimitern, http://reviews.vapour.ws/r/4772/diff/1/?file=346652#file346652line93
[09:17] <fwereade> anastasiamac, ooh, yes please, that would be great
[09:17] <fwereade> anastasiamac, sorry I missed that
[09:18] <anastasiamac> fwereade: thank you. I'll add it to the comment so that Reed keeps track of it :D
[10:55] <axw> fwereade: would you kindly take a look at http://reviews.vapour.ws/r/4776/? fixes one of the critical blockers
[10:59] <fwereade> axw, ack
[11:00] <fwereade> axw, LGTM
[11:00] <axw> fwereade: cheers
[12:58] <fwereade> dimitern, http://reviews.vapour.ws/r/4734/ looks good but undertested
[12:59]  * fwereade bbiab
[14:11] <mup> Bug #1577798 opened: Juju gives unhelpful error when azure out of resource groups <azure-provider> <blocker> <bootstrap> <ci> <juju-core:Triaged> <https://launchpad.net/bugs/1577798>
[14:33] <tych0> http://paste.ubuntu.com/16239197/
[14:33] <tych0> any reason it's looking for lxdbr0 on make install?
[14:47] <rick_h_> aisrael: ping
[14:47] <aisrael> rick_h_: pong
[14:48] <rick_h_> aisrael: got a sec for hangout please?
[14:48] <aisrael> rick_h_: absolutely
[14:51] <mgz> tych0: see pr #5300 - sinzui make the makefile work on a fresh install. yeah, you get kipple in your case, but the install still works, no?
[14:59] <tych0> mgz: it does, it's just weird
[15:03] <mgz> tych0: suggestions on making it less weird welcome
[15:03] <tych0> mgz: yep :)
[15:05] <mgz> tych0: l104 of Makefile - using ifconfig lxdbr0 to find out if the networking is setup, is the cause of the stderr output
[15:06] <mgz> I guess just a 2>&1 would do but maybe there's something smarter
[15:07] <tych0> oh, right
[15:07] <tych0> because make executes the if statements when parsing the file
[15:08] <tych0> mgz: yeah, that seems reasonable to me, do you want to send a patch or should I?
[15:08] <mgz> tych0: go for it
[15:09] <tych0> mgz: ok, will do, thanks
[15:10] <tych0> mgz: https://github.com/juju/juju/pull/5349
[15:13] <mgz> tych0: lgtm
[15:13] <mgz> tested the change locally as well
[15:13] <tych0> mgz: cool, thanks
[15:17] <tych0> mgz: does your LGTM mean that i can $$merge$$? id on't know much about the process here still
[15:18] <mgz> tych0: yes, you can
[15:18] <mgz> and yeah, it's not super clear :) (I didn stamp on the review site)
[15:18] <mgz> hm, though, might be blocking bugs at present
[15:18] <mgz> lets see
[15:19] <mgz> tych0: yeah, like a million
[15:20] <tych0> mgz: ha, ok :0
[15:20] <tych0> :)
[15:59] <mup> Bug #1578337 changed: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:02] <mup> Bug #1578337 opened: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:05] <dimitern> fwereade: thanks for the review on http://reviews.vapour.ws/r/4734/ btw!
[16:06] <dimitern> fwereade: if you're still about, I'm pushing some updates, including the missing tests and will also tackle your suggestions
[16:09] <fwereade> dimitern, cool, thanks
[16:09] <dimitern> fwereade: I'll ping you in the next 30m or so for a final look, while I finish a few more live tests
[16:11] <mup> Bug #1578337 changed: no command to remove controllers <juju-core:Invalid> <https://launchpad.net/bugs/1578337>
[16:16] <natefinch> fwereade: do you have thoughts on what should happen if someone does juju deploy precise/ubuntu --series xenial?  Should it depend on whether or not ubuntu is a multiseries charm or not?  If it's not a multiseries charm, it's pretty clear that this should fail without --force, but if it is a multiseries charm, precise/ubuntu really is the same charm as xenial/ubuntu, so should we let it deploy to xenial without --force, or enforce regularity in
[16:16] <natefinch> the CLI even though --force is not technically needed?
[16:17] <natefinch> also welcome anyone else's thoughts on this.  I'm not really sure I know what the right answer is.  I feel like, either way, we're going to annoy someone
[16:18] <natefinch> I guess, if we're going to annoy people either way, we might as well make it consistent, and require --force.
[16:19]  * natefinch rubber ducks with the channel as a whole.
[16:19] <fwereade> natefinch, ha -- it feels to me like the user is explicitly specifying a charm, and explicitly specifying a series; and expecting us to resolve the charm, discover that it's multiseries and xenial is supported, and do what they told us to
[16:19] <fwereade> natefinch, if it's not multiseries, --force for sure, but I don't think we should need it if they're doing something sane in an unorthodox fashion
[16:20] <natefinch> fwereade: I just have a feeling that it would feel weird that juju deploy precise/ubuntu --series xenial would work, but juju deploy precise/mysql --series xenial would not
[16:21] <fwereade> natefinch, I think of "precise/ubuntu" as a charm selector
[16:22] <natefinch> fwereade: to the user, it's different behavior based on invisible information
[16:22] <fwereade> natefinch, that's always been the underlying intent: what the user types is input to a specific component that resolves an *actual* charm, and we then proceed purely on the basis of the charm we found: it feels odd to me to attach additional weight to the selector, just to make something fail
[16:24] <fwereade> natefinch, deploying "precise/ubuntu" to machines with two different series is, I think, a clear way of specifying that you want the exact charm in both places
[16:24] <fwereade> natefinch, it's not an unreasonable request
[16:24] <fwereade> natefinch, it will succeed or fail based on the charm in either case
[16:24] <natefinch> fwereade: right, but, to an end user, sometimes it'll magically work, and sometimes it'll magically require --force
[16:25] <natefinch> fwereade: I guess that's ok, since working indicates that it's supposed to be ok there, and not working indicates it may well explode
[16:26] <fwereade> natefinch, I think so, yeah
[16:26] <fwereade> natefinch, and if they *really* want to try it they can always --force
[16:26] <natefinch> fwereade: I think that makes sense... it does give the user extra information that "hey this might break" whereas with a multjseries charm we can say "hey, this should work"
[16:27] <fwereade> natefinch, exactly, yeah
[16:28] <natefinch> fwereade: cool. thanks for helping me talk it out :)
[16:28] <fwereade> natefinch, always a pleasure :)
[17:23] <niedbalski> alexisb, ping
[17:25] <alexisb> niedbalski, ping
[17:25] <niedbalski> ericsnow, https://bugs.launchpad.net/juju-core/+bug/1514874 I am seeing this now with 1.25.5, juju is uninstalling after rebooting the units/state.
[17:25] <mup> Bug #1514874: Invalid entity name or password error, causes Juju to uninstall <juju-core:Triaged> <https://launchpad.net/bugs/1514874>
[17:29] <niedbalski> ericsnow, I think that even if 'returned during API open: invalid entity name or password' is a valid cause, throwing a ErrTerminateAgent exception is an over-reaction, instead of putting the connect-try in a loop and log a warn/fatal error.
[17:30] <ericsnow> niedbalski: OTP
[17:32] <perrito666> niedbalski: I thought we had taken care of that
[17:47] <niedbalski> perrito666, I thought the same, but that's probably only on 2.0
[17:48] <perrito666> niedbalski: I am pretty sure we fixed that around 1.21
[17:48] <perrito666> the last time that bit someone was in 1.18, for reference se PS4
[17:48] <ericsnow> niedbalski: taking a look
[17:49] <niedbalski> perrito666, which specific bug?
[17:49]  * perrito666 clicks what niedbalskilinked to see what exactly are we talking about
[17:53] <natefinch> fwereade: still around?
[17:53] <niedbalski> perrito666, well, with 1.25.5 it's quite easy to reproduce; edit the agent.conf of the unit, change the apipassword, and restart. Now it seems that some other condition can be causing this same behavior.
[17:54] <redir> alexisb: what command you working on flattening currently? block?
[17:54] <perrito666> niedbalski: that smells strongly like a regression
[17:54] <alexisb> redir, yep
[17:54] <alexisb> the others are all yours
[17:54] <alexisb> and i am happy to meet and discuss if you like
[17:54] <perrito666> I should know, I have broken agent.conf in very creative ways with restore and juju never uninstalled
[17:54] <alexisb> katco, ping
[17:54] <katco> alexisb: pong
[17:54] <niedbalski> perrito666, I just did it, wiped.
[17:55] <katco> alexisb: sorry was eating lunch earlier. responded to you email
[17:55]  * perrito666 scratches chin
[17:55] <perrito666> niedbalski: is this behavior also present in 2.0?
[17:55] <alexisb> katco, np, I see the response now thank you
[17:55] <alexisb> katco, we are going to want to jump on that bug right away
[17:55] <katco> alexisb: ah, that was 13:00 today?
[17:55] <redir> alexisb: I'm looking through https://github.com/juju/juju/pull/5240/files to see how you tackled it.
[17:56] <niedbalski> perrito666, I can check.
[17:56] <perrito666> niedbalski: if you say yes I am very much about to ring a hughe alarm
[17:56] <katco> alexisb: kk
[17:57] <alexisb> redir, once I am done with my upcoming call we should probably chat, I probably can save you some time
[17:57] <fwereade> natefinch, briefly
[17:58] <natefinch> fwereade: along the same lines as before juju deploy precise/ubuntu currently deploys to xenial, since the selected charm says xenial is best
[17:58] <natefinch> fwereade: bug or feature?
[17:58] <fwereade> anyone who's around, I don't quite have time to look at dimitern's branch but the only thing blocking an LGTM was a lack of unit testing -- I am happy with the code
[17:58] <fwereade> natefinch, ha
[17:59] <fwereade> natefinch, that *does* rather seem to break the law of least surprise, doesn't it :-/
[17:59] <natefinch> fwereade: I actually kind of wish precise/ubuntu wouldn't resolve anymore if ubuntu is a multiseries charm
[17:59] <fwereade> yeah
[17:59] <dimitern> fwereade: thanks! I'm doing a final live test after adding concrete errors as discussed (it was surprisingly hard to do outside of the errors package and still get the same effect)
[18:00] <fwereade> natefinch, the most DWIMmy thing I can think of is to use features of the selector as tie-breakers when the user hasn't otherwise specified
[18:01] <natefinch> fwereade: that seems fair
[18:01] <fwereade> natefinch, cool
[18:01] <natefinch> fwereade: cool, thanks
[18:02] <fwereade> dimitern, hard to do as single error values?
[18:02] <natefinch> core team meeting anyone?
[18:02] <fwereade> natefinch, ...dammit, I can't really :( need to get supper
[18:02] <dimitern> fwereade: well, that would've been a lot simpler, but I wanted to preserve the error stack and the usual way of tracing/annotating
[18:03] <natefinch> fwereade: totally understood :)
[18:03] <fwereade> dimitern, fair enough, but I think once you've understood the situation well enough to pick a specific error the rest of the context is less interesting and can probably be dropped
[18:03] <fwereade> regardless :)
[18:04]  * fwereade gtg
[18:08] <perrito666> so anybody coming to the team meeting?
[18:13] <redir> alexisb: OK.
[18:13] <redir> on the team meeting
[18:18] <dimitern> alexisb, fwereade, also OCRs, etc: http://reviews.vapour.ws/r/4734/ is ready and tested well enough to get approval and land I think, which will fix bug 1321442
[18:18] <mup> Bug #1321442: Juju does not support EC2 with no default VPC <ec2-provider> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1321442>
[18:29] <natefinch> redir: btw - http://juju.fail/ will give you the state blocked release branches
[18:34] <alexisb> redir, I am available when you are
[18:36] <mup> Bug #1501398 changed: Test suite failures with WSARecv timeout <blocker> <centos> <ci> <go1.6> <ppc64el> <test-failure> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1501398>
[18:36] <mup> Bug #1570883 changed: imageSuite.TestEnsureImageExistsCallbackIncludesSourceURL fails on centos go 1.6 <blocker> <centos> <ci> <go1.6> <jujuqc> <lxd> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1570883>
[18:36] <mup> Bug #1578254 changed: Race in apiserver/common and apiserver/proxyupdater <blocker> <ci> <race-condition> <regression> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1578254>
[18:41] <mgz> natefinch, starving his family
[18:55] <alexisb> redir, I am going to step out for a bit for lunch, I will ping you when I am back
[18:55] <redir> alexisb: me too and I'll be back.
[18:57] <mgz> sinzui: should bug 1571914 and so on actually be blockers?
[18:57] <mup> Bug #1571914: github.com/juju/juju/cmd/jujud unit tests fail if xenial is the LTS <juju-core:In Progress by reedobrien> <juju-core 1.25:In Progress by reedobrien> <https://launchpad.net/bugs/1571914>
[18:57] <mgz> we hacked around the failures, but holding up the branch from landing seems perverse
[18:58] <sinzui> mgz: I will make a exception for the LTS fixes. We are running our of time to land those before my hack fails
[18:59] <mgz> sinzui: is it really an exception?
[18:59] <mgz> without the hack, it would be failing tests, which would block
[18:59] <mgz> so, I think redir should land, and we should remove the hack
[19:00] <sinzui> mgz: yes, that is what I mean.
[19:00] <mgz> $$fixes-1571914$$
[19:02] <niedbalski> ericsnow, any idea?
[19:03] <ericsnow> niedbalski: just about to add a lengthy comment to the bug
[19:03] <niedbalski> ericsnow, thanks.
[19:10] <ericsnow> niedbalski: done; hope that helps
[19:21] <redir> mgz that didn't work against master
[19:21] <mgz> redir: let me double check
[19:22] <mgz> redir: I see, only marked as 'high' against master, fixing now
[19:22] <mgz> redir: go again
[19:33] <fwereade> alexisb, http://reviews.vapour.ws/r/4734/ LGTM, none of my issues should block landing
[19:33]  * fwereade disappears again
[20:15] <katco> ericsnow: natefinch: we need to chat rq
[20:15] <natefinch> katco: kk
[20:15] <katco> natefinch: moonstone
[20:33] <alexisb> fwereade, awesome thank you
[20:33] <alexisb> redir, I am back and ready when you are
[20:38] <redir> k
[20:38] <redir> alexisb: gimme 5
[21:11] <redir> sinzui: the s390x /tmp issue is all sorted yes?
[21:11] <sinzui> redir: yes it is
[21:11] <redir> tx
[21:13] <redir> alexisb: there's no cards in leankit for these command updates are there?
[21:14] <redir> alexisb: what about launchpad?
[21:14] <alexisb> redir, no
[21:14] <alexisb> and no
[21:14] <redir> k
[21:14] <alexisb> redir, probably worth adding a card to tanzinite board for this
[21:14] <redir> gx
[21:14] <redir> tx
[21:14] <redir> OK will do alexisb
[21:21] <perrito666> mgz: can you pass me that link for maas images again?
[21:24] <mgz> perrito666: wiki.cloudbase.it/maas
[21:25] <perrito666> tx
[21:35]  * perrito666 kicks his maas until it works
[21:45] <katco> bogdanteleaga: ping?
[21:51] <mup> Bug #1578834 opened: update-alternatives fails to switch between juju-1 and juju-2 <juju-core:New> <https://launchpad.net/bugs/1578834>
[21:54] <perrito666> curiosity, cannot run qemu and vbox at the same time
[21:56] <perrito666> wallyworld: is 1:1 going to happen?
[21:56] <wallyworld> perrito666: yeah, finishing a qa meeting, and also just need to ensure another clash won't happen, will ping in a sec
[21:57] <perrito666> k
[22:52] <axw> menn0: sorry for piking last night, I hope my notes were at least helpful. did you talk about remote lxd / untrusted users vs. profiles at all?
[22:52] <menn0> axw: np. your notes were very helpful.
[22:53] <menn0> axw: we didn't talk about the lxd profiles item much, but the one pager for it is on my plate now.
[22:53] <menn0> axw: can we perhaps talk about it on monday?
[22:53] <axw> menn0: yep, no worries
[22:53] <menn0> axw: i'm a bit pushed for time today
[22:54] <axw> menn0: np, just wondering if it came up that's all. we can talk later
[22:54] <axw> (it only occurred to me while I was writing notes :))
[22:54] <menn0> axw: to be honest, before I saw your notes about it I thought it was only about the lxd provider. I wasn't think about remote lxd containers.
[22:55] <menn0> axw: one thing which was mentioned last night is the Will was pretty sure placement directives were the right way to go.
[22:55] <axw> menn0: it may be, but I meant lxd provider targeting a remote host, not lxd containers
[22:55] <axw> menn0: yeah that's my feeling too
[22:55] <menn0> axw: I haven't put enough thought into it yet
[22:56] <redir> mgz: sinzui: FWIW, both the 1.25 and master fixes for the LTS hack have merged. In case you missed 'em.
[22:56] <mgz> redir: ta
[22:56] <axw> menn0: you can't *yet
[22:56] <axw> *
[22:56] <sinzui> redir: thank you


[11:59] <delinquentme> bzr commit -m "yadda" /path/to/only/files/I/want/committed.rb
[11:59] <delinquentme> right?
[11:59] <jelmer> delinquentme: yes
[12:07] <janos> delinquentme: you might like this too: bzr ci -m 'yadda' -x /path/to/dir/i/want/to/EXCLUDE
[12:18] <delinquentme> janos, Ohh cool! TIL bzr has an exclude option
[12:22] <janos> ...and if you made a mistake with the list of files, you can "bzr uncommit" and try again. but prob you did know that
[12:23] <janos> (unless you're in a central workflow, in which case you should not uncommit...)
[14:30] <mnn> I'm getting an error while shelving changes
[14:31] <mnn> Was this fixed or not? https://bugs.launchpad.net/bzr/+bug/660125
[14:31] <mnn> http://pastebin.com/vHeu7J7R
[14:32] <mnn> I don't know if it's same issue
[14:32] <jelmer> mnn: that bug isn't fixed going by the bug status
[14:33] <mnn> so, is there a workaround?
[14:33] <mnn> will commit work?
[14:34] <vila> wild guess: move the existing file out of the way before shelving (from the bug report the issue is about that existing file not being known by bzr)
[14:35] <mnn> well, I don't have any pending renames - only added files and modified
[14:35] <vila> ha, be looking at your paste, it may be a different issue
[14:35] <mnn> I've been shelving/unshelving stuff for long time now without any issues
[14:36] <vila> the pita with 'mzrlformed transform' is that, while it's clearly a bug in bzr, the error reported is so cryptic there is no way to diagnose without being able to debug locally :-/
[14:36] <vila> so either you're able to 1) publish your branch and working tree 2) isolate a reproducible recipe
[14:37] <vila> 1) may not even be a good solution if too many files are involved (I've lost myself in several attempts already)
[14:38] <vila> mnn: yeah, that's what make bugs of this family so painful, there are less and less corner cases left unaddressed which make them harder to understand and fix :-/
[14:39] <vila> mnn: I think there is another bug about pending adds causing trouble
[14:40] <vila> 'bzr st' would be a good start to check whether you still have unknowns or not or...
[14:41] <vila> mnn: 'will commit work?' It should !
[14:41] <vila> hmm
[14:41] <vila> mnn1: what's the last message you read ?
[14:43] <mnn1> "mnn: I think there is another bug about pending adds causing trouble"
[14:43] <mnn1> got disconnected
[14:43] <vila> ok
 'bzr st' would be a good start to check whether you still have unknowns or not or...
 mnn: 'will commit work?' It should !
[14:44] <vila> in fact, I think it's a very good idea to start with 'bzr commit',
[14:44] <vila> from there it's possible that 'bzr uncommit; bzr shelve' *will* work
[14:44] <mnn1> well this is even more weird - I have 3 modified files, 7 added files and 1 added folder
[14:45] <mnn1> I can shelve all files without any problem and then separately shelve added folder - no crash
[14:45] <vila> shudder
[14:46] <mnn> well but after that qshelve crashes whenever I try to show contents of those shelves
[14:47] <mnn> well, I got something new - "bzr: ERROR: No final name for trans_id 'new-2'"
[14:48] <mnn> this error pops up when I try to unshelve added files
[14:48] <vila> at that point, trying to diagnose whether this a genuine bug or a fallout from the original one is... not worth it IMHO
[14:48] <vila> start by doing a backup of your whole working tree (*including* the '.bzr' directory)
[14:49] <vila> and try to get back to the point where the whole shelve was failing and try 'commit/uncommit/unshelve' instead
[14:49] <mnn> damn, I knew this would happen when I start using VCS
[14:58] <vila> jelmer: python-docutils-0.9.1 ? quantal ?
[14:58] <jelmer> vila: debian experimental
[14:59] <vila> jelmer: hmm, can you try just removing the leading space on that line 161 ?
[14:59] <vila> jelmer: (I know I suck for not having a debian experimental chroot ;)
[15:00] <vila> jelmer: the guess above is because emacs doesn't fontify this line like the other similar ones, cheap enough to try...
[15:01] <jelmer> vila: I'll try
[15:01] <vila> jelmer: wait, wrong guess, *adding* a space *after `fcgi` seem to to fontiry correctly
[15:01] <vila> i.e. a space after the closing `
[15:02] <vila> I don't speak japanese but a space there shouldn't hurt ;)
[15:04] <jelmer> vila: that works \o/
[15:04] <vila> jelmer: \o/ feels good :)
[15:58] <vila> jelmer: approved
[18:22] <lduros> hi, I have Contents conflict on directories that existed but don't exist anymore, and I actually don't have the files themselves in the tree anymore, but the Contents conflict are still there and I'm not sure how to resolve them when the files are gone? Any idea? Thanks!
[18:58] <mark06> about my earlier question on uncommit, is it the same thing for push --overwrite in Launchpad?
[18:59] <mark06> I mean, that push will overwrite the branch but previous versions will still remain in the repository (either local or in Launchpad) just like uncommitted commits?
[19:15] <fullermd> Yes.
[19:15] <mark06> ok, thanks
[19:15] <fullermd> (though I have to scoff at the phrasing "uncomitted commit".  It's thinking about things like that that get people committed  :p)
[19:17] <mark06> I've heard about some gc plugin but couldn't find it to test
[19:18] <mark06> is there some bug to make uncommit, push --overwrite and the like to really do what they say?
[19:38] <fullermd> They do what they say; they make changes to branches.
[19:38] <fullermd> They just don't remove stuff from repositories.
[19:47] <mark06> I knew you would disagree
[19:47] <mark06> why not tweet my uncommits as well
[19:49] <fullermd> I'm sure someone has implemented `bzr push twitter://....`  ;>
[20:02] <mark06> :P
[20:24] <lduros> any idea how to remove "contents" conflicts for files that have now been physically removed?
[20:24] <jelmer> lduros: use "bzr resolved"
[20:25] <lduros> jelmer: with the d at the end? Hmm
[20:25] <lduros> jelmer: it tells me 0 conflicts auto-resolved.
[20:25] <jelmer> lduros: does "bzr conflicts" still report any conflicts?
[20:26] <lduros> jelmer: yes, it still mentions those files that are not present physically
[20:26] <lduros> jelmer: there are also some other text conflicts
[20:26] <lduros> which I need to work on
[20:28] <jelmer> lduros: have you tried "bzr resolved" with a filename?
[20:32] <lduros> jelmer: hmm let me try :-)
[20:33] <lduros> jelmer: ok looks like it's doing the trick! Thanks! :-)


[00:08] <ubptgbot> A was added by: A
 hmmm
 (Photo, 1280x960) https://irc.ubports.com/UXr475Ai.png Tablet is up and running again, time to start the porting of it (doubt it will work, but who knows)
 @Tygerpro [<reply to media>], What tablet is this?
 Asus Transformer Prime, the keyboard comes off
 (Photo, 1280x960) https://irc.ubports.com/AMB7fd2Q.png I miss doing this, website on one side, ssh session to compile on the other
 Hmm, getting errors with a repo sync, interesting
 I know that feel bro
 K that is just weird, I go to compile, with no modification to the source and get fails, added a -i to the end and its ... outputting the expected files?!?! Something isn't adding up
 ... and systemimage is compiling without the -i, am I being punked or something, this is weird
 oooh
 Ok, I got an expected result, it failed, but iirc using -i should -NOT- yield a file if the previous attempt failed
 I think I am goig to need to go with a 7.1 based build over the 5.1 that Im trying
 Ok, the code doesnt want to compile in vanilla form, that does not bode well for porting 🤔
[06:36] <ubptgbot> MariartiPro was added by: MariartiPro
 Good day. Please tell me how to install Ubuntu on Meizu M5s Android 6.0?
 @Tygerpro [Ok, the code doesnt want to compile in vanilla form, that does not bode well for …], I would be contacting you once I start my luck with my HTC 10 😉
[08:38] <ubptgbot> RALPH KEELEY was added by: RALPH KEELEY
[08:38] <ubptgbot> <RALPH KEELEY> RALPHH
[08:38] <ubptgbot> <RALPH KEELEY> [Edit] waited also lengthy with this is occurring you should test this particular away  http://t.cn/AiWCmdJl
 @MariartiPro [Good day. Please tell me how to install Ubuntu on Meizu M5s Android 6.0? …], You can't. The current supported devices list is https://devices.ubuntu-touch.io/ … You can try to port it if that model meets the minimum requirements though … http://docs.ubports.com/en/latest/porting/introduction.html
[09:34] <ubptgbot> trymriverman was added by: trymriverman
 Does anyone know if Nexus 6P is a supported device
 @trymriverman [Does anyone know if Nexus 6P is a supported device], Nope, it isn't, but someone is trying to port it and maybe you can help (?) … https://github.com/Halium/projectmanagement/issues/56
 (Photo, 720x1174) https://irc.ubports.com/rGAah6eK.png
 (Photo, 720x1232) https://irc.ubports.com/WC7m9dW8.png
 (Photo, 718x1122) https://irc.ubports.com/0OItpSGm.png
 Thank. Here are the technical specifications of Meizu M 5s.
 You're welcome :) … Mediatek is usually a bad choice because the source tree isn't available btw
 @advocatux [You're welcome :) … Mediatek is usually a bad choice because the source tree isn't …], So are the Meizu M5s specifications suitable for installing Ubuntu?
 They don't look good to me but it'll be better to wait for an answer from anyone with real porting experience :)
 @advocatux [They don't look good to me but it'll be better to wait for an answer from anyone …], Thank you again) I hope there are people who have experience with such an installation of Ubuntu ..)
 👍
 Just wanted to say: awesome job! Can't wait to get my hands on a suported device...
 @Javacookies [I would be contacting you once I start my luck with my HTC 10 😉], Lol, Im a bit rusty as I havent done anything porting related in awhile due to life stuff, Im just now getting back to a place where I actually have time to do anything, I thought Id give my tablet a go at porting.  I have one last thing I wanna try for port
[11:50] <ubptgbot> ing my tablet before I give up on it
 Huawei unveils harmony os in open-source, will it help to port Ubuntu on Huawei/honor device running this os?
 Dunno, prob not homestly, but yojr welcome to go ahead and try
 is it basically AOSP fork?
 ok, it's not even Linux kernel based, so it won't help us
 It use Android drivers
 And is not a PC distro
 K thx
 https://www.xda-developers.com/harmony-os-huawei-announce/
 "Harmony OS will not allow for root access, which Huawei says is a security risk on Android and other Linux-based operating systems."
 That does not affect UT
 it kinda does in hypotethical case we wanted to port UT to Huawei devices, but it seems they are not putting that OS to phones yet
 @NotKit [it kinda does in hypotethical case we wanted to port UT to Huawei devices, but i …], i guess not, since we don't need root in the existing android install
 not root, but the fact that it is not Linux kernel based
 i don't think that matters. it not having a linux kernel doesn't mean a linux kernel won't run on it
 but more likely, they won't allow unlocking bootloader
 which does matter
 that means we can't rely on hybris and this
 sure, but if bootloader could be unlocked and mainline drivers existed, they could be used
 but i wouldn't worry about it anyway, because huawei is not a nice company
[13:10] <ubptgbot> <Rishi Parmar> True that
 @Kazord [Huawei unveils harmony os in open-source, will it help to port Ubuntu on Huawei/ …], especially support for HTML5 and Linux apps ( I presume x11) is very interesting, maybe it'll be easier to port some apps to UT :-)
 @Stefano0101 [especially support for HTML5 and Linux apps ( I presume x11) is very interesting …], i highly doubt it will be helpful to us in any respect
 @dohbee [but i wouldn't worry about it anyway, because huawei is not a nice company], who told you that? US or UK government? How about Google and Apple and MIcrosoft, they are nice companies? There was a proposal from Huawei to completely get checked their software, source code, all of it is spite of ,, spying'' accusation and nobody
[13:17] <ubptgbot>  cared about it. SO?
 @dohbee [i highly doubt it will be helpful to us in any respect], but UT can run HTML5 apps, so this should be easier to repack it-port it, or no?
 @Stefano0101 [who told you that? US or UK government? How about Google and Apple and MIcrosoft …], stop being defensive of chinese corporations and stick on topic please.
 @dohbee [stop being defensive of chinese corporations and stick on topic please.], ok
 @Stefano0101 [especially support for HTML5 and Linux apps ( I presume x11) is very interesting …], Hum, maybe in term of porting app between both but even on that I have doubts
 @Stefano0101 [but UT can run HTML5 apps, so this should be easier to repack it-port it, or no?], chromeos, webos and firefox os were built entirely around html/js apps. but all those aren't ported to UT
 @dohbee [chromeos, webos and firefox os were built entirely around html/js apps. but all …], but it's still interesting to see something new out there, hope I'm not wrong and it won't turn to Android-ish with apps spying on users... but I suppose it's all about money.
 @Kazord [Hum, maybe in term of porting app between both but even on that I have doubts], it was just a thought.
 @Stefano0101 [but it's still interesting to see something new out there, hope I'm not wrong an …], Maybe not, but it appears it will be locked down. In any case it doesn't exist yet, so debating about it is kinda useless.
[14:11] <ubptgbot> OverCoder was added by: OverCoder
 moo
 baa
 Welcome to the farm
 ok
 can I install this on any device
 or is it only the 7 or whatever many listed devices
 Only the devices listed at devices.ubuntu-touch.io. To install on other devices, you'd need to create a port which requires a bit of knowledge on Android and C (or, alternatively, a will to learn)
 smh I am not a C guy but
 I dealt with C before
 I'll try a bit later maybe
 Well C, C++, it's just helpful to know how stuff gets stuck together
 And what it means when gcc yells at you
 ok I know how stuff gets stuck together
 also
 how does Touch perform on older devices
 point is I am interested into running this on my older devices to make any useful usage of them
 If it shipped with Android 5.1 or 7.1 you're good
 If not you're not
 ok i'm not then
 (some restrictions apply)
 or well, if there is a lineageos 14 port for it, you should be ok, too, assuming it originally shipped with at least android 4.2, i think
 there is not
 We don't support or have all the code for the 4.4 ports
 thing is it is pretty old, .5GB of RAM etc, but like, I just want it to stay connected to Wi-Fi so I can attach a storage to it and use it like a NAS
 technically this wouldn't need more than .2 GB of RAM
 but well
 @OverCoder [thing is it is pretty old, .5GB of RAM etc, but like, I just want it to stay con …], buy a Raspberry Pi for $40 instead
 gg android
 @dohbee [buy a Raspberry Pi for $40 instead], I already have to buy storage first etc., but yea looks like I have to
 Yeah, a different computer might be a better option in that situation. You won't go very far with that little horsepower.
 hmm
 I wish I could instead install like
 Ubuntu Touch is built and designed a phone OS, not a traditional Linux distro
 Arch linux there lol
 maybe you can install postmarketOS
 There is arch for the pi
 @dohbee [maybe you can install postmarketOS], checking that out
 it's more like what you're looking for i guess
 wait I just remember, I have an actual device that should do well
 hmm
 @UniversalSuperBox [Ubuntu Touch OTA-10 is slated for release on Wednesday, August 14, 2019. You can …], Woooot!
 The Forum is up & running again 👍
[15:38] <ubptgbot> Ethan Sligar was added by: Ethan Sligar
[15:39] <ubptgbot> <Ethan Sligar> Would this be able to run on the samsung galaxy note 10.1 (2012)
 Is it ok to ask here if anyone would like to sell me their nexus 7 tablet, or Bq m10 FHD? PM, located in Europe.
[15:46] <ubptgbot> stanza was added by: stanza
 Ho guys. I own a BQ E4.5 with ubuntu version 15.04 installed
 Is it possible to upgrade it? I think that the phone was sold with ubuntu pre installed
 @stanza [Ho guys. I own a BQ E4.5 with ubuntu version 15.04 installed], Welcome. Yes, upgrade is possible. I think you should just need to use the installer.
 I installed it on my linux box. It tells me to reboot phone in bootloader mode. After doing that the installer seems to be stuck, it does not (maybe) recognize the device
 @stanza [I installed it on my linux box. It tells me to reboot phone in bootloader mode. …], make sure you have `fastboot` and `adb` tools installed
 (Photo, 1280x720) https://irc.ubports.com/0oxuRyE0.png
 I have them installer
 Installed. The installer is stuck this way, see the photo
 Unfortunately I do not know how to proceed further in the installation
 Should I file a bug? Or am I missing something?
 Does this work on the samsung galaxy note 10.1
 2012
 No
 Ok
 NOOK HD+?
 Fwd from UniversalSuperBox: Only the devices listed at devices.ubuntu-touch.io. To install on other devices, you'd need to create a port which requires a bit of knowledge on Android and C (or, alternatively, a will to learn)
 Thanks
 Fwd from UniversalSuperBox: Only the devices listed at devices.ubuntu-touch.io. To install on other devices, you'd need to create a port which requires a bit of knowledge on Android and C (or, alternatively, a will to learn)
 Second try
 @stanza [Should I file a bug? Or am I missing something?], please join https://t.me/WelcomePlus for more installation help. it's a group we have specifically for help with installation issues
 @dohbee [please join https://t.me/WelcomePlus for more installation help. it's a group we …], Thanks, I'll give it a try. I think I am experiencing big 845 of ubports-installer
 @dohbee [please join https://t.me/WelcomePlus for more installation help. it's a group we …], [Edit] Thanks, I'll give it a try. I think I am experiencing bug 845 of ubports-installer
[16:29] <ubptgbot> <John (Marlin)> @UniversalSuperBox [Ubuntu Touch OTA-10 is slated for release on Wednesday, August 14, 2019. You can …], I added comments on a few issues relevant to my device (Nexus 5). In the blog post I noticed the change log included a wireless display fix, but my phone detects the connected device and hangs on connecting. Is that still a known
[16:29] <ubptgbot>  issue not fixed?
 @John (Marlin) [I added comments on a few issues relevant to my device (Nexus 5). In the blog po …], are you connecting to a MS Wireless Dislay Adapter?
[16:32] <ubptgbot> <John (Marlin)> @dohbee [are you connecting to a MS Wireless Dislay Adapter?], Miracast. Generic, I think. Not sure.
 I can only guarantee it works with a Microsoft Display Adapter
 And even then, not that well
 Right, there may be other issues with other adapters. it's only ever really been tested well with the MS adapter
 also, are you on stable or RC?
[16:34] <ubptgbot> <John (Marlin)> @UniversalSuperBox [And even then, not that well], It used to be consistent with detecting the adaptor. Now I have to switch Wireless Display on and off a few times before it's detected. No problem connecting with Android though.
[16:34] <ubptgbot> <John (Marlin)> @dohbee [also, are you on stable or RC?], I was on devel, but just now switched to rc for the QA feedback.
 ok
 @Tygerpro [Lol, Im a bit rusty as I havent done anything porting related in awhile due to l …], okay then after you give up, buy an HTC 10 and help with the port 😝 … trust me, it can be like a "flagship" of UT...well specs-wise and features 😁
 Lol, Ive got a note 4 port I should finish as well
 @Javacookies haven't seen you in porting channel :)
[19:56] <ubptgbot> CthulhuPrelate was added by: CthulhuPrelate
[21:06] <ubptgbot> Mohammed_HL was added by: Mohammed_HL


[03:07] <Baron1984> http://ubuntuforums.org/showthread.php?p=5194590#post5194590
[17:42] <popey> @schedule
[20:55] <DktrKranz> !now
[20:55] <DktrKranz> mh...
[20:55] <lukehasnoname> @now
[20:55] <Seveas> DktrKranz, try @now :)
[20:56] <DktrKranz> heh, thanks :)
[20:56] <lukehasnoname> !@now
[20:56] <ScottK> @!now
[21:20] <\sh> hmm
[22:00] <ScottK> Hello everyone.  I have it as time to start the motu-sru meeting.  Who is here?
[22:00] <\sh> moins
[22:01]  * ogra lurks
[22:01]  * geser watches from the back
[22:01] <TheMuso> Greetings.
[22:01]  * DktrKranz is here
[22:02] <ScottK> No jdong or cody-sommerville
[22:02] <LaserJock> I'm stopping by and wanted to say a couple things at some point if that's ok
[22:02] <ScottK> \sh, DktrKranz, TheMuso: Who is running this meeting?
[22:03] <TheMuso> Do we have an agenda?
[22:03]  * heno listens in
[22:03] <\sh> aehm.how wanted it? :)
[22:03] <ScottK> I think it was get together and make a plan.
[22:03]  * sbeattie is also lurking
[22:03]  * ScottK considers 4 of 6 a good quorum and suggests we start.
[22:04] <ScottK> Any objections to letting LaserJock say his piece at the beginning?
[22:04] <TheMuso> No.
[22:04] <DktrKranz> No.
[22:04] <ScottK> LaserJock: Go.
[22:04] <\sh> fire away pls :)
[22:04] <LaserJock> well, I wanted to just brief people on the script I've been working on
[22:04] <LaserJock> in collaboration with Steve Beattie who is the Canonical SRU QA Engineer (I think that's right)
[22:05] <LaserJock> http://qa.ubuntuwire.com/sru/ is the current site
[22:05] <LaserJock> and I've got an hourly cron job producing 3 pages
[22:05] <ScottK> LaserJock: Very good work.  Particularly for someone who's taking a break from Ubuntu.
[22:05] <ScottK> ;-)
[22:06] <LaserJock> well, this is the *only* thing I'm doing *buntu related
[22:06] <LaserJock> and it was started before I started my break
[22:06]  * ScottK appreciates it.
[22:06]  * DktrKranz even more
[22:06]  * TheMuso  also.
[22:06] <ScottK> Much easier to work from than Launchpad.
[22:06] <LaserJock> so we'd like to get feedback from you guys as primary users
[22:07] <ScottK> I think DktrKranz has been doing the most SRU stuff lately.
[22:07] <DktrKranz> I tried to, at least
[22:07] <LaserJock> the other thing is that the QA team is working on some specs related to SRU work
[22:07] <LaserJock> heno and sbeattie, who are lurking ;-) are working on those specs
[22:07] <ScottK> I think before we can know much about that, I think we need to talk about process for Universe.  I think it's pretty broken right now.
[22:08] <LaserJock> I'd really love to see the MOTU SRU team working well with the QA team to get the consistency and quality of SRUs up
[22:08] <heno> agreed
[22:08] <ScottK> Perhaps one of you can tell me how we got from the old process to one where only the sru-verification team can verify a Universe SRU?
[22:08] <ScottK> I've looked through the MOTU meeting minutes and can't find where that was agreed to.
[22:09] <ScottK> heno: Unfortunately I think the current situation really isn't very suitable for Universe.
[22:09] <LaserJock> ScottK: that's not actually true at all
[22:09] <LaserJock> anybody can verify SRUs
[22:10] <ScottK> LaserJock: No they can't.  Only sru-verification can tag them verified.
[22:10] <LaserJock> the sru-verification team, from what I understand, is there to *ensure* that SRU (Main mostly) are done
[22:10] <ScottK> At least per the written process.
[22:10] <LaserJock> hmm, that's not how I read it
[22:10] <ScottK> Historically that was true, but no longer.
[22:10] <heno> depends what you mean by verify -- do the verification work or ack that it was verified correctly
[22:11] <heno> the formed should be open to many people
[22:11] <heno> *former
[22:11] <LaserJock> ScottK: hmm, I can see how you could read it both ways
[22:11] <ScottK> LaserJock: https://wiki.ubuntu.com/StableReleaseUpdates very clearly says it's the verification team that tags it done.
[22:11] <LaserJock> it's not clear to me
[22:11] <LaserJock> I read that that is their function, but not to the exclusion of other people
[22:12] <DktrKranz> indeed, I've seen some SRUs (for main too) copied to -updates without a "thumbs up" from sru-verification but after a large testing by users
[22:12] <LaserJock> however, the SRU page sometimes gets edited without telling people ;-)
[22:12] <ScottK> Yes.  This isn't about who tests, but who can say it's good.  Although no where on that page does it actually ask for community testing/results.
[22:12] <LaserJock> "Verification feedback from bug reporters and subscribers is greatly appreciated"
[22:13] <ScottK> OK.
[22:13] <LaserJock> though that is very far down the page
[22:13] <ScottK> It also says, "The SRU verification team may also discover that your fix is good. They will: - Modify the verification-needed tag to a verification-done tag on the bug report."
[22:13] <LaserJock> right
[22:13] <ScottK> That's pretty clear and how I understand it's historically been done in Main.
[22:13] <LaserJock> which to me doesn't exclude other people from doing so
[22:14] <LaserJock> but says that there is a team in place to catch the ones that may fall through the cracks
[22:14] <ScottK> That's the only step in the process where it's mentioned
[22:14] <DktrKranz> well, sru-verification is not closed, someone can join in (as I did, basically to perform verifications for Universe)
[22:15] <ScottK> What it appears to me happened is that motu-sru was told to go document Universe process differences and instead then just dropped them.
[22:15] <ScottK> https://wiki.ubuntu.com/MOTU/Meetings/2007-11-23
[22:15] <DktrKranz> but it's a bottleneck, especially for universe
[22:15] <LaserJock> in any case, IMO, a sru-verification team is unnecessary if SRU QA is in place
[22:15] <ScottK> "The Universe SRU Policy shall be reviewed by the members of ~motu-sru, and the rationale for variations from the policy for Main will be documented."
[22:15] <LaserJock> DktrKranz: what is a bottleneck? sru-verification or verification in general?
[22:15] <ScottK> No where does it say go drop all the differences.
[22:16] <LaserJock> ScottK: no, we decided to drop
[22:16] <DktrKranz> LaserJock, having sru-verification to check bugs, IIRC it's just me who perform "regular" scan in universe packages
[22:16] <ScottK> Who and when?  Such a decision is not documented?
[22:16] <ScottK> LaserJock: ^^^
[22:16] <LaserJock> ScottK: the MOTU SRU team did, and it'd only be documented in an IRC log I belive
[22:16] <heno> IMO we don't have enough people doing verifications in main _or_ universe so pooling those (testing) teams would be good
[22:17] <LaserJock> DktrKranz: well, I totally ignored it
[22:17] <ScottK> LaserJock: I don't think the MOTU SRU team had that authority.  They changed something that affects all of Universe without asking anyone else.
[22:17] <LaserJock> ScottK: umm, yeah, it was our authority
[22:17] <ScottK> From where?
[22:17] <ScottK> The MOTU Meeting minutes say document the differences, not remove them.
[22:17] <LaserJock> by virtue of being the MOTU SRU team
[22:17] <DktrKranz> heno, having hug days targeted to SRU verification?
[22:18] <heno> DktrKranz: that'd be good!
[22:18] <ScottK> LaserJock: I disagree.  We've had a policy for quite some time now that process changes get decided by MOTU.
[22:18] <LaserJock> sru-verification team should most likely go away
[22:18] <LaserJock> ScottK: no, we don't
[22:18] <LaserJock> we have a process of letting relevant teams make decisions
[22:18] <LaserJock> not nit-picking every single policy change
[22:18] <heno> pedro has been doing both bug days and universe verification - he could probably set that up
[22:18] <ScottK> I think motu-sru decide how it wants to make it's decisions, but not to change overall process that affects everybody.
[22:19] <ScottK> LaserJock: So far we're down to one person focused on Universe who can verify SRUs.  That's no nit picking.
[22:19] <LaserJock> no, it's not
[22:19] <TheMuso> I think this all came out of the idea that we wanted to allign ourselves with the process for main somewhat more, and so it was decided that our process was as close to main as possible.
[22:19] <LaserJock> that's utterly untrue
[22:19] <LaserJock> *anybody* can verify an SRU
[22:20] <ScottK> LaserJock: That's not what the wiki page says.
[22:20] <LaserJock> yes it is
[22:20] <LaserJock> though I agree that it's unclear
[22:20] <LaserJock> but the operational reading of that, IMO, has been that anybody can verify
[22:20] <ScottK> LaserJock: OK.  I don't think it's at all unclear and I don't think that's what it says.
[22:20] <LaserJock> then change it
[22:21] <LaserJock> no biggie
[22:21] <ScottK> Can anyone mark an SRU verified or just MOTU?
[22:21] <LaserJock> *anybody*
[22:21] <ScottK> heno: Is it OK per process if I mark a Main SRU with the verification done tag?
[22:21] <LaserJock> if it's badly marked MOTU SRU or pitti will pick that up
[22:22] <heno> ScottK: if you feel qualified, yes. it still needs to be let through by an archive admin
[22:22] <\sh> hmm...anybody with bug powers can mark an SRU verified, even if it's the worst nightmare ?
[22:23] <heno> that's where the real gatekeeping happens
[22:23] <ScottK> OK.  Then I think the wiki page needs a lot of work on that because I don't see that at all as written.
[22:23] <heno> \sh: why would you do that just for fun?
[22:24] <ScottK> heno: We have people with Launchpad accounts we definitely don't want marking verification done.
[22:24] <heno> generally it's only done by the QA in practice
[22:24] <sbeattie> note that even if a good verification has been done and tagged, a package may not necessarily get moved into the archive if it's felt that more test usage is needed to catch any regressions.
[22:24] <\sh> heno: oh...not just for fun, but because I know at least one person without a clue but thinking he does the right things, even if he didn't ...
[22:24] <\sh> heno: and believe me, 1+n with n <3 want to play gatekeeper for crap
[22:24] <\sh> archive admins I mean
[22:24] <heno> so in MOTU the tag triggers the upload basically?
[22:24] <DktrKranz> heno, if a user publishes a clear verification (by attaching screenshots, terminal logs, and so on), I'd say it's ok, taggind and stating "works for me" is somewhat "incomplete" to me
[22:25] <LaserJock> ok, hang on a sec
[22:25] <LaserJock> 1) I've not seen any badly tags SRUs
[22:25] <LaserJock> 2) The MOTU SRU team and the archive team can both easily revert the tag
[22:26] <LaserJock> if something looks phony, revert it
[22:26] <LaserJock> not a problem
[22:26] <ScottK> I don't think anyone is aware they are allowed to tag.  I certainly wasn't.
[22:26] <heno> yeah, trying to restrict tag use isn't practical
[22:26] <ScottK> Unless I misunderstood DktrKranz last week, he joined sru-verification because he thought he had to to tag stuff verified.
[22:26] <LaserJock> hmm, I was just doing it, naughty me ;-)
[22:27] <\sh> because tasks and tags are two different things...but work tasks we don't have in LP ;)
[22:27] <DktrKranz> ScottK, basically yes
[22:27] <LaserJock> ok, so my suggestion:
[22:27] <LaserJock> 1) edit SRU page to be clear about who can use tags, etc.
[22:27] <LaserJock> 2) discuss with Ubuntu SRU and QA team about eliminating sru-verifcation team
[22:28] <LaserJock> IMO, we're developing QA tools that should obsolete the sru-verification team
[22:28] <ScottK> Makes sense.
[22:28]  * DktrKranz agrees
[22:28] <sbeattie> LaserJock: heh, sru-verification is the subscriber that I'm querying off of.
[22:28] <DktrKranz> we're moving in the right direction, and we have some good tools already
[22:29] <ScottK> While we can't restrict tag use formally, I do think a motu/core-dev ought to sign off on a verification.
[22:29] <LaserJock> sbeattie:  that's why we need to "discuss"
[22:29] <LaserJock> ScottK: well, Ubuntu Archive does that
[22:29] <\sh> LaserJock: who is "we"? and which QA team? ubuntuwire or canonical qa?
[22:29] <ScottK> LaserJock: The archive admins don't scale very well.  I think developers ought to do the initial verification.
[22:30] <heno> \sh: there is an Ubuntu QA team too ;)
[22:30] <LaserJock> ScottK: well, MOTU SRU can always do it
[22:30] <DktrKranz> LaserJock, I think we should take more responsibility and leave a-a just administrative tasks, not verification ones
[22:30] <LaserJock> heno: no there isn't, last I looked
[22:30] <heno> LaserJock: https://wiki.ubuntu.com/QATeam
[22:30] <heno> we have weekly meetings here
[22:31] <ScottK> LaserJock: I agree we can do it, but I don't think we should be a choke point on the back end of the process.
[22:31] <LaserJock> \sh: sbeattie and I at the moment, hosted on ubuntuwire and eventually on qa.ubuntu.com perhaps
[22:31] <LaserJock> heno: if it doesn't have an LP it doesn't exist ;-)
[22:31] <LaserJock> ScottK: well, I'd say go easy on it and re-evaluate after a while of processing perhaps. My experience is that people flipping the tag is the least of the problems
[22:32] <heno> LaserJock: you can discuss these things with a team of people, not an LP team ;)
[22:32] <LaserJock> heno: you don't know who to talk to if there isn't an LP team
[22:32] <LaserJock> heno: especially when there *is* a Canonical LP team
[22:33] <ScottK> LaserJock: I really don't want to write down a process that says it's OK for someone like Kmos to set an SRU to verified.
[22:33] <LaserJock> ScottK: why not?
[22:33] <LaserJock> it's easy to change if it's wrong
[22:33] <ScottK> Only if the archive-admin catches it.
[22:33] <LaserJock> it much easier to let the 99.9% good stuff go through unhindered then block all 100% because of it
[22:33] <LaserJock> ScottK: but MOTU SRU is there the whole time
[22:33]  * \sh 's wife will kill him...
[22:34] <ScottK> Any SRU has a MOTU that sponsored it, so they should be able to follow-up on the verification.
[22:34] <LaserJock> sure
[22:34] <LaserJock> I just don't think it needs to be limited
[22:34] <LaserJock> but I'm not on the team anymore so ... :-)
[22:35] <\sh> ScottK: and the sponsor is mostly not sitting in the SRU team
[22:35] <ScottK> Exactly.
[22:35]  * ajmitch reads the scrollback & tries to catch up
[22:35] <\sh> ajmitch: simple workflow matters ;)
[22:35] <DktrKranz> \sh, when sponsors do sponsoring :)
[22:36] <ajmitch> \sh: sure...
[22:36]  * ScottK has ~10 minutes until he goes.
[22:36] <LaserJock> overall I think the current process is good
[22:36] <LaserJock> but the SRU page needs to be fixed
[22:36] <\sh> DktrKranz: if they have the guts to sponsor SRU..which could harm their powers
[22:37] <ScottK> I think the current process only worked because virtually no one knew about it.
[22:37] <LaserJock> 1) doesn't tell people they need to wait for MOTU SRU ack
[22:37] <LaserJock> 2) doesn't describe versions well
[22:37] <LaserJock> 3) needs to be more procedural. i.e. answer "I want to submit and SRU, how do I do that?"
[22:38] <LaserJock> ScottK: enough people knew about it to create a lot of SRUs
[22:38] <LaserJock> and I don't see any reason why it wouldn't scale decently well
[22:38] <LaserJock> IMO the biggest missing piece was good tracking, and I think we're going to get that handled much better
[22:39] <ScottK> It's the verification part I'm talking about.
[22:39] <DktrKranz> it's not that hard to have a SRU in -proposed, the hard part is having it in -updates
[22:39] <ScottK> LaserJock: I do think your script is a big step forward.
[22:40] <LaserJock> yes, well the nature of many Universe SRUs doesn't lend themselves to ready verification
[22:40] <LaserJock> lot's of weird, specific cases where something fails
[22:40] <ScottK> DktrKranz: You've the most recent experience with the process.  Would you be up for drafting a proposed update to the wiki?
[22:41] <slangasek> fwiw, I do share ScottK's concern that ubuntu-archive shouldn't be trying to judge whether the person setting the verification-done tag is qualified to do so
[22:41] <DktrKranz> ScottK, if we motu-sru can work on it to have a good candidate, sure
[22:41] <ScottK> I'll be glad to help.
[22:41] <ScottK> slangasek: Thanks.
[22:41] <LaserJock> slangasek: for sure
[22:41] <LaserJock> my point is that the subscribers and MOTU SRU all get bugmail
[22:42] <ScottK> True.
[22:42] <LaserJock> and lastly Ubuntu Archive
[22:42] <LaserJock> *somebody* is going to catch a bogus verification change
[22:42] <ScottK> Hopefully.
[22:42] <slangasek> LaserJock: but not necessarily before the archive admin du jour does the copy to -updates?
[22:43] <slangasek> LaserJock: does there need to be a minimum review period between setting the tag and copying the package?
[22:43] <LaserJock> no
[22:43] <LaserJock> it's whenever pitti gets to it
[22:43] <LaserJock> we already have a 7-day aging in -proposed
[22:43] <\sh> because pitti doesn't scale..
[22:43] <LaserJock> pitti scales just fine
[22:44] <LaserJock> this is really not a bandwith-heavy process
[22:44] <LaserJock> it just requires people paying attention to it
[22:44] <DktrKranz> pitti is doing a *huge* job, anyone subscribed to sru-verification can confirm
[22:44] <slangasek> but the bug may be unverified for 8 days, then be marked "verified" by someone not qualified to know, and the copy happens right after that without review?
[22:44] <ScottK> slangasek: Yes.
[22:44] <DktrKranz> if we can help it to just doing archive admin task, it will be good
[22:44] <slangasek> fwiw, https://wiki.ubuntu.com/ArchiveAdministration#head-18b6747493b60de8de4b4ceaef46ac8e705d3231 suggests that copying packages to -updates is part of the archive team's duties, not just pitti's :)
[22:44] <LaserJock> slangasek: yep
[22:44] <DktrKranz> it/him
[22:45] <ScottK> This is why we really need to minimize what the archive-admins have to face.
[22:45] <LaserJock> slangasek: sure, pitti's just the one that does it
[22:45]  * ScottK needs to go.
[22:45] <ScottK> Read you all later.
[22:45] <LaserJock> the archive-admins don't have much to face
[22:45] <LaserJock> there's a lot to do, for sure
[22:45] <\sh> ok...i don't get it...
[22:45] <LaserJock> but like I said, I've never seen a bogus verification
[22:45] <\sh> we have a queue of let's say 7 to 8 days in -proposed
[22:46] <lukehasnoname> later ScottK
[22:46] <\sh> after that period, someone tags it as "verfied" and A-A of the day just copies it from a to b ..
[22:46] <\sh> now, for user x * 1000 this update make things worse
[22:46] <\sh> because unknown master of puppets set the flag of "yeah it works"?
[22:47] <LaserJock> no
[22:47] <LaserJock> it needs to be in -proposed for 7 days *and* have 2 + acks and no -'s
[22:47] <LaserJock> and the whole time multiple people are watching it
[22:48] <DktrKranz> LaserJock, mh... sometimes not
[22:48] <LaserJock> so I'm fairly sure within reason people catch all the problems
[22:48] <LaserJock> DktrKranz: that's failure in executing the established process, not failure in the process itself
[22:48] <DktrKranz> exactly
[22:49] <DktrKranz> we should enforce it
[22:49] <LaserJock> but MOTU SRUs job is to make sure that the process is exectuted correctly
[22:50] <DktrKranz> sometimes motu-sru is hijacked, rare cases, but it happened
[22:50] <LaserJock> so, as long as that's happening, and MOTU SRU has the tools it needs then all is good
[22:50] <LaserJock> well, then MOTU SRU needs deal with that
[22:50] <geser> if a package in the -proposed queue doesn't get confirmed for 7 or 8 days, then either a) there was a communication problem or b) the package is less used
[22:51] <LaserJock> well, currently we have form 0 days to 80+ days in -proposed
[22:51] <LaserJock> *from
[22:51] <DktrKranz> geser, users think about -proposed as a "regular" repository, if a package works, that's enough
[22:51] <heno> having many more people use -proposed would help because we would catch the worst breakage -- thousands would be good
[22:51] <DktrKranz> my experience is only 5% commented on bugs
[22:51] <LaserJock> heno: I disagree
[22:51] <slangasek> geser: ehm, do you want me to count the bugs on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html for hardy/universe that haven't bee confirmed yet after > 10 days?
[22:51] <LaserJock> heno: I don't think -proposed should be just "enabled"
[22:52] <LaserJock> I'd much rather have links to .debs in -proposed
[22:52] <heno> if just 1% of those who run the devel releases ran -proposed we'd be doing well
[22:52] <DktrKranz> heno, if we suggest to enable it, we should be prepared to another X breakage
[22:52] <DktrKranz> and we need to have -proposed-proposed :P
[22:52] <TheMuso> I don't think proposed should be enabled by default at all.
[22:53] <heno> DktrKranz: people are prepared for that on the devel release
[22:53] <LaserJock> I don't think proposed should be enabled for general users, ever
[22:53] <heno> TheMuso: no clearly not
[22:53] <TheMuso> Particularly since there is the occasional big update, i.e alsa-lib for hardy, that is likely to break things for users, and unless they know how to downgrade again, its somewhat unsafe.
[22:53] <geser> slangasek: I just looked at the page. I didn't expect to see that many "main" packages with > 10 days in the queue.
[22:53] <sbeattie> LaserJock: I don't think we want all users to run -proposed, but we do want far more power users to use it.
[22:53] <heno> obviously, neither should the devel release ...
[22:53] <LaserJock> sbeattie: we can't control that
[22:54] <slangasek> geser: in the case of hardy/main, many of them are d-i components that couldn't be tested at all until just recently
[22:54] <LaserJock> with the devel release, when something breaks we say "well, you were warned, tough luck"
[22:54] <LaserJock> with -proposed we lose testers, and reputation because we told people to enable it
[22:54] <heno> LaserJock: right we should warn people
[22:54] <sbeattie> what heno said.
[22:54] <LaserJock> if you turn -proposed into essentially the same as devel then you lose a lot of people
[22:55] <heno> but if the same people ran it they would know the risks
[22:55] <LaserJock> well, that does make some sense for common Main packages, I admit
[22:55] <heno> LaserJock: that's not what we're suggesting
[22:55] <LaserJock> but it makes little sense for many Universe packages
[22:55] <LaserJock> because you *have* to know the test cases anyway
[22:55] <heno> just that people with the same risk awareness run it
[22:55] <LaserJock> so you just enable -proposed as a convenience
[22:56] <LaserJock> which opens up your testers to potentially hundreds of new packages
[22:56] <DktrKranz> when people enable -proposed, they catch almost everything because version is bigger than stable release, if we could tell "ok, this is a proposed upgrade, install it for testing purposes", it should be better
[22:56] <LaserJock> when they only want/need to test one or two
[22:56] <\sh> heno: you just made a distinction between common world users who just want to use something which is broken, and the hard boiled egg sysadmin who knows what he does...
[22:56] <heno> LaserJock: you have to know the test case to verify the fix but not catch severe regressions
[22:56] <\sh> heno: regarding d-i examples of slangasek, yes, the sysadmin will do some testing
[22:57] <LaserJock> heno: which is really and odd thing
[22:57] <LaserJock> we aren't looking for sever regression!
[22:57] <\sh> heno: regarding simple tomboy nobody will test this, because they just want to use it.
[22:57] <LaserJock> we are wanting to verify that an SRU fixes what it's supposed to fix
[22:57] <geser> would a apt pinning like debian backports or debian experimental help so people don't get all -proposed updates automatically?
[22:57] <slangasek> there was discussion recently on ubuntu-devel about how best to enable -proposed
[22:57] <LaserJock> just enabling -proposed does *nothing* towards that
[22:57] <slangasek> I still think that apt pinning + update-manager support is the best solution
[22:57] <heno> but the bad regressions are the thing we really worry about, so 'just using' is helpful
[22:57] <LaserJock> geser: I would be for that
[22:57] <LaserJock> slangasek: agreed
[22:58] <LaserJock> heno: again, only for a certain class of SRUs
[22:58] <DktrKranz> I agree with slangasek
[22:58] <LaserJock> evolution for instance
[23:00]  * \sh needs to read the logs tomorrow morning...his wife has a knife in her hand and tells him to shut down the computer, or she will kill him...cu tomorrow folk
[23:00] <LaserJock> \sh: cya
[23:00] <LaserJock> ;-)
[23:00] <DktrKranz> when doing SRUs, changelogs entries are "incomplete", they do not tell users which issues they are addressing, thus leaving users a doubt if a -proposed update is worth a risk for a regression
[23:00] <slangasek> \sh: it's a trick, once the computer's off there are no witnesses
[23:00] <LaserJock> lol
[23:01] <DktrKranz> if we document better what we are addressing, people looking at -proposed from update-manager will be encouraged to test
[23:01] <LaserJock> how concerned are we about major regressions outside of the kernel, X, and perhaps microrelease exception packages?
[23:01] <sbeattie> LaserJock: here's an example: gnome-games had fixes for a couple of the solitaire games, but the update that was pulled in also caused glchess to fail to start.
[23:02] <sbeattie> LaserJock: we didn't catch it, but upstream did, fortunately before it made it into -updates.
[23:02] <LaserJock> sbeattie: right, we *should* catch that
[23:02] <sbeattie> Agreed, we should.
[23:02] <LaserJock> i.e. mass uploading Gnome into -updates is not high on my recommendation list
[23:02] <sbeattie> How, with the resources we have, is the tricky question.
[23:03] <LaserJock> well, there are a couple things
[23:03] <LaserJock> 1) catch it before we release
[23:03] <sbeattie> LaserJock: well, that's unfortunately out of my control, despite my agreement with that.
[23:03] <LaserJock> QA before release helps a *ton* when it comes to SRUs
[23:03] <sbeattie> LaserJock: point is, if you *only* went to verify the bugfixes (which is what I did), you missed that regression.
[23:04] <LaserJock> 2) perhaps use a staging PPA to look for regressions
[23:04] <LaserJock> yes, but my point is that is *precisely* why we have our current SRU policy
[23:04] <sbeattie> I agree it would be helpful to let people pick and choose which proposed packages they wish to test.
[23:05] <sbeattie> But we *also* want to tap our expert users and help us catch regressions in updates to scary packages like dpkg.
[23:05] <geser> I see a problem with universe packages that only 5 people have installed and only one finds a SRU worthy bug, how will you find regressions there?
[23:06] <slangasek> ask all 5 users to try it, if none find regressions, then by definition they don't exist ;)
[23:07] <DktrKranz> sbeattie, what about improving https://wiki.ubuntu.com/QATeam/PerformingSRUVerification and widespread it?
[23:07] <sbeattie> DktrKranz: heno and I are trying to do exactly that.
[23:08] <DktrKranz> good starting point
[23:08] <heno> we'll get there :)
[23:08] <heno> LaserJock's tracking pages will help publicize it
[23:09] <DktrKranz> as I said before with heno, having targeted days on SRUs will surely help and people could become more interested and willing to help
[23:09] <heno> DktrKranz: I'll try to get one set up next week
[23:10] <heno> (I'll CC you on an email)
[23:11] <DktrKranz> good
[23:11] <sbeattie> I wonder if there's a way we can do more targeted notifications, so we can inform those 5 users in geser's example that there's a package in -proposed that we'd like them to help test?
[23:13] <LaserJock> publishing an SRU RSS feed with bug URL and test case would be good
[23:13] <DktrKranz> we already have instruments (pinning a-la-debian), just lack UI
[23:14] <sbeattie> LaserJock: a) heno has asked me to set that up, but b) it needs to be filterable so you don't get spammed with packages you don't use.
[23:17] <geser> sbeattie: what about enabling -proposed by default so update-manager sees new packages and can notify the user. But with apt-pinning so they don't get automatically installed / marked for installation.
[23:18] <sbeattie> That's a possibility worth exploring.
[23:19] <heno> hm, I'm worried about people agreeing to install by accident
[23:19] <LaserJock> sbeattie: does it need to be filtered?
[23:19] <DktrKranz> I fear users will be tempted to install *everything*, we should document changes better at a first glance, as for security updates, for instance
[23:20] <heno> it should be strictly opt-in
[23:20] <geser> it would also help if update-manager didn't mark all -proposed packages for upgrade by default. /me has used some time to uncheck all -proposed updates when using update-manager and wanted only some from -proposed (e.g. firefox 3.0)
[23:20] <heno> perhaps an installable notification applet
[23:20] <LaserJock> well, why not do both ways
[23:21] <LaserJock> 1) allow people to just enable -proposed as now, these are the bleeding edgers looking for regressions
[23:21] <DktrKranz> update-manager do distinction between security and updates, why not adding a third type "proposed/testing packages" ?
[23:21] <LaserJock> 2) in an SRU tracker set up links to .debs for people who are specifically testing a fix
[23:21] <geser> isn't there one? I remember seeing one the last time
[23:22] <geser> DktrKranz: ^^
[23:22]  * DktrKranz opens hardy VM to check
[23:22] <DktrKranz> just a couple of minutes
[23:22] <LaserJock> DktrKranz: it does
[23:22] <sbeattie> LaserJock: re filtering: you use $EDITOR; do you wish to be notified when $OTHEREDITOR gets moved into -proposed?
[23:23] <LaserJock> sbeattie: maybe, but that's the fun of RSS
[23:23] <LaserJock> *we* can't tell what people want
[23:23] <LaserJock> so we let them intelligently filter themselves
[23:25]  * heno wanders off for the night; it's getting late here
[23:25] <heno> LaserJock: thanks for alerting me to the meeting
[23:26] <heno> It's been enjoyable :)
[23:26] <LaserJock> heno: thanks for coming
[23:26] <DktrKranz> gnight heno, please keep me informed if you plan to do some hug day, I'll be happy to help :)
[23:26] <DktrKranz> hah, late :P
[23:26] <TheMuso> heh
[23:33] <DktrKranz> LaserJock, could you point us to some specs related to QA SRU you talked earlier?
[23:35] <sbeattie> https://wiki.ubuntu.com/Testing/fix-validation-tracking is one
[23:42] <DktrKranz> mh, it seems we ran out of topics :)
[23:43] <DktrKranz> should we summarize and go to bed?
[23:43] <LaserJock> DktrKranz: yeah, I thought you already did
[23:43] <LaserJock> :-)
[23:43] <LaserJock> it seemed to me the broad topics were:
[23:44] <LaserJock> 1) "fixing" and clarifying the SRU policy wiki page
[23:44] <LaserJock> 2) tracking SRUs and what tools are needed
[23:44] <LaserJock> 3) how to get verification done better
[23:44] <LaserJock> sound about right?
[23:44] <DktrKranz> perfect
[23:46] <DktrKranz> I'll give a first try at 1)
[23:46] <LaserJock> I'm working some on 2)
[23:46] <LaserJock> and I think 3) needs more dialog, IMO
[23:46] <DktrKranz> let's do 3) with QA, maybe lurking at their meetings
[23:46] <LaserJock> yeah
[23:47] <LaserJock> I would encourage MOTU SRU to at least lurk at QA meetings
[23:47] <sbeattie> LaserJock: do you think you got sufficient input on 2)?
[23:47] <DktrKranz> I will, given that timing permits it
[23:47] <LaserJock> because I consider SRU to be a part of QA
[23:47] <LaserJock> sbeattie: well, I'm not sure
[23:48] <DktrKranz> 17 UTC... bad timing :(
[23:48] <DktrKranz> I'm on my way back from office
[23:48] <LaserJock> sbeattie:  there were'nt any objections though, so that's good
[23:49] <sbeattie> LaserJock: just wondering if there were additional ideas (besides an RSS feed some slacker *cough* should set up) to enhance tracking.
[23:50] <LaserJock> DktrKranz: can you think of any other "tool" that would help you with SRUs?
[23:52] <DktrKranz> LaserJock, nothing right now, I'll think a bit about what we should have
[23:52] <LaserJock> DktrKranz: awesome, thanks
[23:52] <sbeattie> Was trying to figure out if there was a way to pull out who tagged a fix as verification-done out of launchpad, but I don't think it's possible. Need to dig more.
[23:52] <sbeattie> Given the concerns that were raised earlier.
[23:53] <DktrKranz> sbeattie, addind to bug history perhaps?
[23:53] <DktrKranz> it shouldn't be too difficult
[23:54] <DktrKranz> e.g. https://bugs.edge.launchpad.net/ubuntu/hardy/+source/amavisd-new-milter/+bug/226845/+activity
[23:54] <DktrKranz> if we can have who tagged it in there, could be enough
[23:56] <sbeattie> Yeah, I don't see the tag history in there. But that would be the logical place for it to appear.
[23:57] <DktrKranz> sbeattie, I'll search through malone bugs to see if there's something similar already and file a new bug otherwise
[23:57] <LaserJock> the Launchpad "history" isn't always very complete
[23:58] <LaserJock> sbeattie: I honestly think it's a waste of your time and cpu cycles
[23:58] <sbeattie> DktrKranz: https://bugs.edge.launchpad.net/malone/+bug/56630
[23:58] <DktrKranz> good :)
[23:58] <LaserJock> we get bugmail
[23:58] <LaserJock> and if somebody is consistently abusing the tag then we'd notice
[23:59] <sbeattie> LaserJock: sure, was just thinking if it was easy to pull out, it'd be easy to add as a column  to the verification-done table.


[21:22] -ubottu:#ubuntu-ops- jailbreak called the ops in #ubuntu-offtopic (irish leaving and joining spam.)