[00:23] <bodie_> would be great if I could get a quick LGTM so I can get this dep update in
[00:23] <bodie_> https://github.com/juju/charm/pull/5
[00:23] <bodie_> nvm, think I'm covered
[00:25] <jcw4> I would appreciate a quick review on https://github.com/juju/names/pull/8 ... it's only documentation and variable name changes to clarify intent
[00:26] <jcw4> diffstat +14 -14
[00:30] <bodie_> just stepping away to eat, I'll get you after if nobody else has
[00:30] <jcw4> bodie_: thanks
[00:35] <rick_h_> thumper: will check back with you.
[00:36] <jcw4> wallyworld: tx
[00:36] <wallyworld> np
[01:08] <waigani> thumper: you about?
[01:12] <jcw4> wallyworld; new pull request https://github.com/juju/juju/pull/116  (diffstat +56/-43)
[01:12] <jcw4> I'm afraid I don't know the irc nick for Horacio?
[01:12] <wallyworld> jcw4: jut finishing another review, will look real soon now
[01:12] <wallyworld> jcw4: it's perrito666 but he's likely asleep now
[01:13] <jcw4> thanks wallyworld
[01:13] <jcw4> perrito666: Sorry didn't know you were he :)
[01:15]  * jcw4 steps away for a while
[01:21] <sinzui> thumper, I want to do that in 2 days. Juju HA/backup-reatore is broken. If I must release, I will take a revision from last week. This what we had to do for 1.19.3 as well
[01:27] <thumper> waigani: ya
[01:28] <thumper> sinzui: ack
[01:28] <thumper> rick_h_: hey, back now
[01:29] <sinzui> perrito666, I not really. I see a few of these cases, but they resolve themselve in a 2nd run http://juju-ci.vapour.ws:8080/job/aws-deploy-precise-amd64/1323/console
[01:30] <waigani> thumper: in the factory tests e.g. TestMakeUserAny, if I add c.Assert(saved, jc.DeepEquals, user), it fails
[01:30] <waigani> thumper: ... mismatch at (*(*).doc.DateCreated.loc).name: unequal; obtained "Local"; expected "UTC"
[01:31] <waigani> thumper: if I call user.DateCreated().Location().String() - it returns "UTC", even when in the doc the loc name is "Local"
[01:31] <wallyworld> sinzui: there's some critical stuff landed this week which we can't ship 1.20 without, so if we do release 1.19.4 with a rev from last week, we'll need to do a 1.19.5 as well
[01:32] <thumper> waigani: push up your latest, and I'll grab it and look here
[01:32] <sinzui> perrito666, Merge pull request #79 from perrito666/translate_backup_to_go is the last good rev for backup-reatore. A lot of branches landed while joyent and ha stalled ci for 21 hours
[01:32] <jcw4> wallyworld: you're a machine... thanks :)  I'll add those comments and split that test
[01:32] <rick_h_> thumper: hey, let me know when you get a sec
[01:32] <wallyworld> awesome, thank you
[01:33] <sinzui> perrito666, commit ba83d11 is the last good commit for backup-restore
[01:33] <thumper> rick_h_: I'm just munching right now, let me finish eating and help waigani
[01:33] <rick_h_> thumper: rgr
[01:33] <sinzui> wallyworld, I think that is a given, juju has not proven itself to be stable for user
[01:34] <wallyworld> sinzui: i've not got to the joyent root cause of suckiness yet. how is hp looking?
[01:34] <sinzui> in a word, *fucked*
[01:34] <waigani> thumper: I don't have anything to push. Just add this test to testing/factory/factory_test.go and you'll see the problem: http://pastebin.ubuntu.com/7661265/
[01:35] <thumper> ok, let me look
[01:35] <wallyworld> sinzui: but we think it's because of cloud resourcing issues rather than juju per se right?
[01:35] <sinzui> wallyworld, I region-b doesn't have writable provider storage. The test failed, This is the error I always see with HP http://juju-ci.vapour.ws:8080/job/hp-upgrade-precise-amd64/1349/console
[01:36] <wallyworld> axw: morning. any chance of you looking at bug 1329477 today?
[01:36] <_mup_> Bug #1329477: Destroying a juju machine with the manual provider, does not completely shutdown any services installed on that machine <destroy-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1329477>
[01:36] <sinzui> wallyworld, since that error is with 1.18.4. I know the problem is Hp
[01:36] <axw> wallyworld: yep, sure. just fixing up ec2 again, will take a look after
[01:36] <wallyworld> axw: ta
[01:36] <wallyworld> sinzui: that may be, still makes it horrible to know if juju is good or not
[01:37] <sinzui> wallyworld, the functional tests that failed do have working stable and devel jujus. The only change I made to the functional tests was to extend the timeout
[01:38] <waigani> thumper: the test name is out of date - I started with testing s.Factory.MakeAnyUser(), but the root, it seems, is in s.State,AddUser which is storing DateCreated with a local location
[01:38] <wallyworld> sinzui: you talking about the "functional-*" jobs?
[01:38] <sinzui> yes
[01:39] <wallyworld> so they're all red right now except for one
[01:39] <wallyworld> i guess that's with the smaller timeout
[01:39] <waigani> thumper: do you want to pair?
[01:40] <thumper> waigani: actually, what is your problem?
[01:40] <thumper> yeah
[01:40] <thumper> hangout
[01:40] <thumper> waigani: start one
[01:41] <davecheney> omg, state has it's own version of names.ParseTag
[01:41] <davecheney>         for _, name := range bad {
[01:41] <davecheney>                 c.Logf(name)
[01:41] <davecheney>                 coll, id, err := state.ParseTag(s.State, name)
[01:41] <davecheney>                 c.Check(coll, gc.Equals, "")
[01:41] <davecheney>                 c.Check(id, gc.Equals, "")
[01:41] <davecheney>                 c.Assert(err, gc.ErrorMatches, `".*" is not a valid( [a-z]+)? tag`)
[01:41] <davecheney>         }
[01:41] <davecheney> which has IDENTICAL FUNCTIONALITY
[01:41] <waigani> thumper: https://plus.google.com/hangouts/_/gwtpvhcmdtc52fcnhi4c2bmglya?hl=en
[01:42] <thumper> davecheney: colour me unsurprised
[01:42]  * davecheney is running out of furnature to throw
[01:42] <davecheney> this will be the next victim once I get this PR proposed
[01:43] <davecheney> coll, id, err := state.ParseTag(s.State, m.Tag().String())
[01:43] <davecheney> this function takes a tag, as a string, and parses it into it's kind and its id
[01:43] <davecheney> m is a machine
[01:44] <davecheney> where does m.Tag() get the string it returns from ?
[01:44] <davecheney> by calling NewMachineTag(m.tag)
[01:44] <davecheney> where m.tag is the string versino of the tag without the prefix
[01:44] <davecheney> so all that nonsense is just to get the value of m.tag
[01:45] <davecheney> and you know what the collection is, because you passed in a machine
[01:45] <davecheney> so clearly it's the machines collection ...
[01:53] <sinzui> wallyworld, http://juju-ci.vapour.ws:8080/job/hp-deploy-precise-amd64/ is a first time pass. My tuning the the env and extra cleanup of HP has had a positive affect.
[01:53] <wallyworld> \o/ well done!
[01:56] <sinzui> ha ha canonistack passes when I serve streams from other clouds
[01:56]  * sinzui needs to file an rt tomorrow
[01:59] <sinzui> I wrote a script last Friday to delete 10 terabytes of disk files left on Azure.
[02:05]  * davecheney shrieks
[02:12] <thumper> rick_h_: around?
[02:12] <rick_h_> thumper: hanging in there
[02:12] <thumper> rick_h_: wanna hang with me?
[02:12] <rick_h_> sounds like a party
[02:12] <rick_h_> your link or mine?
[02:12] <thumper> https://plus.google.com/hangouts/_/gtnotdg6x5r34ae6zuuwuenssia?hl=en
[02:17] <axw> wallyworld: can we have an "investigating" section under Doing in leankit?
[02:17] <wallyworld> sure, sounds reasonable
[02:19] <wallyworld> axw: done
[02:19] <axw> wallyworld: thanks
[02:20] <waigani> thumper: okay got it, you needed to return a pointer reference in order to be able to return a nil
[02:42] <jcw4> davecheney: yep I stumbled across that today... I thought maybe it was a legacy of when the code was organized differently
[02:43] <davecheney> jcw4: it's on my shit list
[02:45] <jcw4> let me know if there's any grunt work you want me to do on that
[02:45] <jcw4> davecheney:
[02:47] <davecheney> jcw4: you can review my branch in an hour or so
[02:47] <jcw4> davecheney: will do
[02:47] <davecheney> basically i'm starting at state and working outwards
[02:47] <jcw4> yes, I have a pending PR that touches some of that too
[02:48] <davecheney> urgh
[02:48] <davecheney> in state
[02:48] <davecheney> or the api we have a thing called params.Entity
[02:48] <davecheney> and an entity has a tag
[02:48] <davecheney> why _isnt_ it a Tag
[02:48] <davecheney> ?!?
[02:48] <jcw4> You mean the Tag() that returns string :)
[02:49] <davecheney> jcw4: that is also on my shit list
[02:49] <jcw4> sweet
[02:57] <bodie_> https://github.com/juju/juju/pull/118
[02:57] <bodie_> Actions as a Hook in uniter
[02:57] <bodie_> pretty simple
[03:29] <jcw4> Addressed comments by wallyworld, PTAL https://github.com/juju/juju/pull/116
[03:30] <wallyworld> jcw4: will do, thanks. i marked the previous version as LGTM as I trusted you to make the changes. i'll take another look though :-)
[03:30] <jcw4> Oh, right... thanks and then I'll $$merge$$ it after you look.
[03:31] <sinzui> I have procs and files left behind from a manual provisioning test. There is no juju or juju-mongodb running, but I cannot provision the machine. What can I delete
[03:31] <sinzui> juju-db.conf
[03:31] <sinzui> <IP_ADDRESS> is already provisioned ["juju-db.conf\njujud-machine-0.conf"]
[03:35] <wallyworld> axw: ^^^^^^^^^^^^^^^
[03:35] <wallyworld> jcw4: tests look much nicer, thanks for splitting them up
[03:36] <wallyworld> sinzui: axw is working on that bug now
[03:36] <jcw4> wallyworld: my pleasure tx
[03:56] <axw> sinzui: weird, I couldn't repro. do you have steps to?
[03:57] <sinzui> axw Not really. CI seems to be doing for the ppc manual tests
[03:57] <sinzui> http://juju-ci.vapour.ws:8080/job/manual-deploy-trusty-ppc64-devel/
[03:58] <sinzui> axw, I found jujud amd juju-mongod running on that machine and the failure. I deleted /var/lib/juju then killed the procs
[03:59]  * sinzui doesn't know any other way to clean up after a failed provisioning
[03:59] <sinzui> axw, I have had lots of failed provisioning on these machines because of egress access to download the tools and charms. IS fixed the egress access today
[04:00] <sinzui> axw, ssh as<EMAIL_ADDRESS>[04:00] <axw> ta
[04:01] <sinzui> axw export JUJU_HOME=~/cloud-city/
[04:01] <sinzui> juju switch kvm-local-trusty
[04:01]  * sinzui thinks
[04:02] <sinzui> oh, axw , I have everything garbled
[04:03] <sinzui><EMAIL_ADDRESS>is bootstrapping <IP_ADDRESS> with the  manual-trusty env
[04:03] <axw> ok
[04:04] <sinzui> axw, the staging key will get you in to look at the evidence
[04:06] <axw> sinzui: FWIW, the right way to clean up a machine is "sudo killall -SIGABRT jujud"
[04:08]  * sinzui pastes that into notes
[04:18] <davecheney> https://github.com/juju/juju/pull/119
[04:18] <davecheney> wow
[04:18] <davecheney> sorry for the massive changeset
[04:22] <axw> sinzui: also, "destroy-environment --force" will not terminate manually provisioned machine agents
[04:22] <axw> (apart from the bootstrap one)
[04:22] <sinzui> oh, then
[04:22] <sinzui> I will need to add something to cleanup between tests
[04:22] <axw> sinzui: manual should always do destroy-environment without --force to be safe
[04:23] <axw> otherwise killall
[04:23] <axw> yeah, I think that's safest
[04:23] <axw> killall -SIGABRT jujud and then wait until it's gone
[04:25] <jcw4> davecheney: my pull request that just went in may need a little work to get the same refactor applied
[04:26] <jcw4> davecheney: since my pr already landed it may have to be merged in your pr :-/
[04:32] <jam> mgz: ping when you're around
[05:07] <davecheney> jcw4: no worries
[05:07] <davecheney> 'tis but a small matter of typing
[05:08] <jcw4> davecheney: hehe, but you only have so many keystrokes in your lifetime...
[05:09] <davecheney> jcw4: thanks, thanks for that thought
[05:09]  * davecheney prepares his resignation
[05:09] <jcw4> >:-}
[05:42] <davecheney> jcw4: thanks for the review
[05:42] <davecheney> what TZ are you in ?
[05:46] <jcw4> davecheney: US West Coast... UTC -7 right now
[05:46] <davecheney> o/
[05:46] <jcw4> \o
[05:47] <jcw4> Its a fun timezone, I get to hang out with the cool kids down under and in Europe
[05:48] <davecheney> \( ﾟ◡ﾟ)/
[05:48] <davecheney> i'm not child
[05:48] <davecheney> i just act like one online
[05:48] <jcw4> haha
[05:48] <jcw4> me either/too
[05:49] <jcw4> davecheney: you in NZ / AU ?
[05:49] <davecheney> AU
[05:49] <jcw4> cool
[05:59] <davecheney> go, tests, go !
[06:01] <jcw4> if you're really compulsive like me you have the console output of the CI on your screen
[06:04] <davecheney> same
[06:04] <davecheney> the job's not done til finished: SUCCESS
[06:05] <davecheney> now to address some of those TODOs
[06:15] <davecheney> i gotta get a faster machine
[06:15] <davecheney> this branch has taken too long because of how long it takes to run/fix/run/fix/run/fix the tests
[06:17] <davecheney> and before anyone mentions the cloud
[06:17] <davecheney> this 2 year old x220 laptop is _faster_ than anything aws has to offer
[06:18] <davecheney> and I have graphs to prove it
[06:44] <davecheney> https://github.com/juju/juju/pull/120
[06:44] <davecheney> one more before i sign off
[07:08] <bigjools> jam1: your email about git diffs has (probably unintentionally) made me laugh a lot
[07:09] <bigjools> or are you jam2 today...
[07:09] <jam2> bigjools: probably jam2 by accident
[07:09] <jam> there we go
[07:10] <jam> bigjools: I can certainly appreciate the humor.
[07:11] <bigjools> jam1: I know this particular horse has been flogged to death already, but that was just hilarious
[07:39] <voidspace> morning all
[07:39] <voidspace> jam: wallyworld: thanks for the reviews guys
[07:39] <jam> voidspace: happy to help
[07:39] <voidspace> jam: wallyworld: one point I disagree with
[07:39] <jam> hopefully its useful feedabck
[07:39] <voidspace> jam: yep, good stuff
[07:40] <voidspace> especially moving the code out of the ServeHTTP method and restructuring
[07:40] <voidspace> discussion of headers etc
[07:40] <voidspace> jam: wallyworld: on moving the asserts into the "mockBackup" function
[07:40] <voidspace> jam: wallyworld: I actually really dislike that
[07:41] <voidspace> jam: wallyworld: I think it's much cleaner to have that function do the setup work / store the information about how it was called
[07:41] <voidspace> and keep the asserts inside the body of the test method
[07:42] <voidspace> if the issue is storing the parameters on the test suite I can provide another object to store them on and avoid polluting the suite
[07:43] <voidspace> plus, state.Info() seems fine to me as a name (returning a state.Info). state.StateInfo() seems a bit redundant :-)
[07:43] <TheMue> morning
[07:43] <voidspace> I'll add these as comments for further discussion on the PR
[07:44] <TheMue> dimitern: happy birthday
[07:45] <jam> voidspace: StateInfo isn't what I'd use, but IIRC ian was asking for MongoConnectionDetails or something significantly more descriptive.
[07:45] <jam> voidspace: I don't think we want to use suite level attributes as they cross contaminate tests
[07:46] <jam> (the suite object is shared between all testts, which is how SetUpSuite can maintain its state)
[07:46] <voidspace> jam: oh, yuck
[07:46] <jam> voidspace: I'm personally fine with asserts in functions that are defined inside that test
[07:47] <jam> voidspace: arguably the "right" way is to create a struct type, and a channel, call the body, in the body have it push the updated info out the channel, and read in from the channel in the rest of the test
[07:47] <voidspace> jam: I prefer the pattern: call the code under test, then assert about how it behaved.
[07:47] <jam> then it is asynchronous safe as well
[07:48] <voidspace> heh
[07:49] <voidspace> it's not asynchronous safe because of the patched module
[07:49] <voidspace> at least in the sense that we can't parallelise the tests when we use PatchValue
[07:49] <jam> voidspace: well once you've done the patching ,you can then call "go Backup()" and there isn't a race.
[07:49] <jam> but no
[07:49] <jam> we can't parrallelise 75+% of our tests
[07:50] <voidspace> I could push a struct into a channel, it's slightly unnecessary complexity but I like it conceptually
[07:50] <jam> voidspace: it isn't terrible to just have a var struct if you prefer that to the complexity of a channel
[07:50] <jam> so "var data struct {backupName string; mongoPort int; ...}
[07:50] <jam> data.backupName = backupName
[07:51] <voidspace> yep
[07:51] <voidspace> thanks, I'll get on those fixes
[07:52] <jam> voidspace: its certainly better than the "data = []" tricks I did in python because of local vs global vs notlocal scoping
[07:53] <jam> voidspace: IIRC nonlocal fit the use case, but wasn't available in the versions of python we were supporting.
[08:19] <dimitern> TheMue, thanks! :)
[08:25] <voidspace> jam: yeah, nonlocal solves exactly that problem
[08:56] <wallyworld> voidspace: hi, sorry, my car broke down when i was getting my kid from school. had to wait for tow truvk etc, back now. that pattern i suggested is what we use everywhere else. it asserts the values passed into the function are as expected and makes more sense to me
[08:57] <wallyworld> mgz: axw ok for standup now if you guys are free
[08:58] <voidspace> wallyworld: hey, we get to sprint with you guys in Lexington
[08:58] <wallyworld> \o/
[08:58] <voidspace> wallyworld: which is cool
[08:58] <wallyworld> very cool
[08:59] <voidspace> wallyworld: do we have offices there?
[08:59] <wallyworld> yes
[08:59] <wallyworld> i'm told lexington is a hole though
[08:59] <voidspace> right, makes sense
[08:59] <voidspace> heh
[08:59] <axw> wallyworld: heya. can you give me 5-10 please? wasn't expecting you back, need to get my daughter dinner
[08:59] <voidspace> it's not far from Boston though
[08:59] <wallyworld> middle of nowhere, nothing to do
[08:59] <wallyworld> no gun ranges
[08:59] <axw> lol
[08:59] <voidspace> wallyworld: the Boston Python user group (biggest user group in the USA) is on Monday
[08:59] <voidspace> wallyworld: ned batchelder and crew - it would be good if we can make it
[09:00] <wallyworld> axw: sure, i may be eating myself, but we'll sync up i'm sure
[09:00] <TheMue> what’s the current status of the lexington sprint?
[09:00] <wallyworld> voidspace: +1 to that
[09:00] <voidspace> TheMue: it's been approved
[09:01] <voidspace> TheMue: it's natefinch's team and wallyworld's team
[09:01] <TheMue> voidspace: ok
[09:02] <TheMue> voidspace: alexisb also asked who else of the other teams will join
[09:03] <voidspace> TheMue: I didn't see anyone else on the sprint list
[09:04] <TheMue> voidspace: ah, so maybe this plan changed
[09:09] <mgz> wallyworld: no one in the standup?
[09:12] <axw> mgz: wallyworld is having some dinner, he'll ping in a bit
[09:12] <mgz> k
[09:17] <wallyworld> mgz: axw: there now
[09:18] <perrito666> morning
[09:33] <jam> dimitern: thanks for the review. I believe I've responded to all your requests if you want to refresh https://github.com/jameinel/juju/pull/1
[09:34]  * menn0 is back for more...
[09:34] <dimitern> jam, cheers, i've reviewed it again, still LGTM
[09:35] <jam> great. I plan on just merging the last of the series, once we've gone through them all.
[09:35] <jam> thanks for starting on the next one.
[09:35] <jam> menn0: run, run while you still can ! :)
[09:36] <menn0> jam: it's ok... I had a lot of distractions today so am catching up now
[09:37] <dimitern> jam, next one is lgtm as well
[09:38] <jam> menn0:  you don't understand… its not safe for you here… dimiter…. oh my god, dimiter. He's reviewing all the code… he's.. reviewing… *all*… the code…. *sob*
[09:38] <jam> thanks dimitern
[09:38] <menn0> LOL!
[09:54] <dimitern> jam, last one reviewed as well
[09:59] <dimitern> fwereade, are you around?
[10:01] <dimitern> fwereade, when you can spare some time, i'd really like you to review the networking model doc https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/
[10:02] <jam> dimitern: fwereade said earlier that he isn't feeling very well today, so he may be in and out a bit
[10:03] <jam> I still need to finish looking at that doc as well.
[10:03] <jam> dimitern: I responded to the idea about FacadeVersions.
[10:03] <jam> my personal opinion is that a map is not a structure for the API itself.
[10:04] <dimitern> jam, ah, right ok
[10:04] <dimitern> jam, why?
[10:05] <jam> dimitern: it seems odd to me that the textual byte stream requires that results must be parsed into a dict
[10:05] <jam> yes that is what we actually do with it once we've gotten it
[10:05] <jam> but it doesn't seem like the stream of data itself is a map
[10:06] <dimitern> jam, i'm a bit thick today is seems :/ what's the byte stream textual rep has to do with it? :)
[10:07] <jam> dimitern: so the API returns data on the wire, which we then read, right?
[10:07] <dimitern> jam, it is essentially a map name-to-versions, right?
[10:07] <dimitern> jam, yep
[10:07] <jam> It seems odd to me that you would require that to be a JSON object type, rather than a list type.
[10:07] <dimitern> jam, if it's an actual map, we can do fast lookups with the results directly, no need for helper methods
[10:07] <jam> We do use it as a dict type
[10:08] <jam> dimitern: well, the first thing we do is put it into a map for storing, but that is just iterating the result and storing it.
[10:08] <dimitern> jam, it's not a dict per se, it's an object
[10:09] <dimitern> jam, right, but if that's something we need to do all the time on the client it seems sub-optimal
[10:09] <jam> dimitern: well it is being done anyway regardless of whether it is explicit or implicit
[10:09] <dimitern> jam, i.e. if the most common operation on these results will be "what versions has the facade named Foo?"
[10:10] <jam> dimitern: well, I liked that it was a sorted list, fwiw
[10:10] <jam> which you can't easily code into a map structure.
[10:10] <dimitern> jam, wait a sec :)
[10:10] <jam> dimitern: FacadeRegistry.List() returns a sorted list of the versions
[10:11] <dimitern> jam, are we talking about the same things here? I mean the FacadeVersions slice, not the Versions slice inside it - the latter will be sorted still if []FacadeVersions becomes FacadeVersionsMap
[10:12] <dimitern> jam, the only thing we'll lose with a map is the keys can't be sorted
[10:12] <jam> dimitern: it is a sorrted list of names each containing sorted versions.
[10:13] <dimitern> jam, so the names being sorted as well is nice, but doesn't contribute much (except for displaying them perhaps, which can be done with sorting), and makes lookups harder
[10:14] <jam> and putting that *into* a map is a rather trivial loop which is exactly what is done in line 48 of state/apiserver/state.go where you commented about us sorting the version ints.
[10:14] <wallyworld> jam: any chance of a review? https://github.com/juju/charm/pull/6 fixes critical 1.19.4 bug 1330919
[10:14] <_mup_> Bug #1330919: local charm deployment fails with symlinks <charms> <regression> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1330919>
[10:14] <wallyworld> or fwereade
[10:15] <jam> wallyworld: fwereade is mostly out sick today, I'll give it a look
[10:15] <wallyworld> ok, thanks, whenever you are free
[10:16] <jam> wallyworld: should we be checking that the target is inside the REPOSITORY ?
[10:16] <jam> I'm generally hesitant about just letting symlinks point anywhere
[10:16] <wallyworld> jam: hmmm. i could do
[10:16] <wallyworld> i guess i never figured it mattered
[10:16] <jam> wallyworld: I'm not *positive* about it, since maybe its ok
[10:17] <jam> but I'd like us to *think* about it first
[10:17] <jam> wallyworld: would we want to just use "filepath.EvalSymlinks" ?
[10:17] <jam> http://golang.org/pkg/path/filepath/#EvalSymlinks
[10:18] <wallyworld> probably, i'm not very familaiar with those api calls
[10:18] <wallyworld> i can tweak it
[10:19] <wallyworld> jam: inside the dir.go code, i don't think we even know what REPOSITORY is
[10:19] <wallyworld> so i guess any check would have to be external to that
[10:21] <jam> wallyworld: sure. as for EvalSymlinks, I just mean we can potentially replace the resolveSymlinkRoot entirely with just rootPath, err := filepath.EvalSymlinks(rootPath)
[10:22] <jam> technically it resolves any symlink anywhere along the path, but I don't think that is a problem for us.
[10:22] <jam> and it means less code we have to write/maintaine
[10:22] <wallyworld> jam: yeah, just tried, that, test failed. but i'll make it work
[10:23] <wallyworld> jam: also, we seem to have a plethora of these new juju repos. the new lander just does juju/juju. tarmac doesn't handle them either i don't expect
[10:23] <wallyworld> looking at previous pr's, it seems people landed by hand perhaps
[10:24] <jam> wallyworld: thats my guess
[10:24] <jam> we *should* have them all under the bot,but people who have been pulling stuff out of Juju haven't been diligent about it
[10:24] <jam> at least IMO
[10:24] <wallyworld> yep, +1. that was my thought too, just wanted to check
[10:24] <natefinch> MOrning all
[10:25] <jam> well, maybe in your opinion as well :)
[10:25] <jam> morning natefinch
[10:26] <voidspace> natefinch: morning
[10:31] <dimitern> jam, ok, still LGTM though, I'd rather have this landed, we can refactor it later if need be
[10:32] <jam> dimitern: can you LGTM the juju/juju pr?
[10:32] <jam> https://github.com/juju/juju/pull/100
[10:37] <stub> wallyworld: (as the bug reporter) I think symlinks should be followed in the repository blindly, but symlinks in the charm should be contained within the charm. It is interesting currently that $JUJU_REPO/precise can be a symlink but $JUJU_REPO/precise/foo cannot (fails per bug report)
[10:37] <wallyworld> stub: yeah, that's how i've done the fix
[10:39] <dimitern> jam, done
[10:43] <jam> dimitern: thanks, I'll go look at the networking doc now
[10:50] <dimitern> jam, TheMue, standup?
[10:51] <TheMue> ouch, yes, comming
[11:18] <wallyworld> stub: that bug is fix committed; if you run from source you can try it out. be sure to get the latest juju/charm code as well as juju/juju
[11:18] <stub> ta
[11:21] <mgz> wallyworld: it's just on the bundling up side right, so no faffing with uploading alternative tools to test?
[11:22] <vladk> dimitern: please, take a look https://github.com/juju/juju/pull/121
[11:22] <wallyworld> mgz: yup
[11:22] <wallyworld> mgz: i think so
[11:22] <wallyworld> or hangon
[11:22] <wallyworld> no
[11:23] <wallyworld> i think you may need new tools too, not sure
[11:23] <wallyworld> i did test and seem to recall i needed to redo the tools
[11:23] <wallyworld> could be wrong
[11:58] <jam> yay, it has finally landed !!
[12:28] <jam> vladk: while you are waiting for dimitern's review of your work, it would probably be helpful to have you look over his networking document: https://docs.google.com/a/canonical.com/document/d/16SYAlZFc19YPXrB7BRwufZVoeLFpqGzBTAdo4EoQIHg/edit?disco=AAAAAJrgVD8#heading=h.8afzt9469s6q
[12:30] <dimitern> vladk, you've got a review, ping me if you have questions please
[12:32]  * perrito666 notices travel agency got something wrong and is trying to send him to london
[12:42] <perrito666> jam: you should also look into gitk/gitg which makes git trees navigation a lot less painful
[12:42]  * perrito666 answers mails via irc, brain wires crossed
[12:42] <jam> perrito666: it still doesn't handle my diff problem well, as they do the equivalent of "git show"
[12:42] <jam> I have tried
[12:42] <jam> I've also tried Atlantassian's SourceTree
[12:43] <perrito666> jam: mm, I thought they had more features
[12:43] <jam> which is pretty nice, but doesn't do what I want
[12:43] <jam> perrito666: so you *can* select a range, and eventually get what you want, but it is clumsy
[12:43] <jam> the default of just selecting a rev shows you the equivalent of "git show"
[12:53] <perrito666> ok, syntax highlight in the comments is nice
[12:57] <mfoord> damn internet connection
[12:58] <perrito666> mfoord: again?
[12:58] <mfoord> perrito666: still
[12:58] <mfoord> perrito666: my line has degraded to 1.6mb downstream
[12:58] <mfoord> perrito666: I haven't sorted it yet
[12:58] <mfoord> perrito666: got on the case a bit this morning - but of course tech support from my isp is awful
[12:59] <mfoord> anyway
[12:59]  * mfoord lunches
[13:40] <wwitzel3> natefinch: oops, just looked at the clock
[13:40] <wwitzel3> natefinch: hopefully you forgot too ;)
[13:56] <natefinch> wwitzel3: yeah, was busy helping with the kids, forgot we had a new meeting this morning
[13:57] <natefinch> wwitzel3: we can do it after the standup
[13:58] <ericsnow> natefinch, wwitzel3: standup in an hour, right?
[13:58] <wwitzel3> ericsnow: correct
[13:59] <natefinch> ericsnow: yep
[14:04] <bodie_> morning all
[14:06] <jcw4> morning bodie_
[15:00] <natefinch> wwitzel3, ericsnow, voidspace, perrito666: the TOSCA meeting is running over, so we will need to move the standup back about half an hour
[15:00] <perrito666> natefinch: ok
[15:22] <tasdomas> I'm having a little trouble understanding the relation between state/api, state/apiserver and state/apiserver/client in juju
[15:35] <jcw4> tasdomas: me too; I think the doc/api.txt file may help some but I'm a little fuzzy about that myself
[15:35] <voidspace> yay, internet back
[15:35] <voidspace> for now anyway :-/
[15:35] <voidspace> I *really* need a dongle
[15:35] <voidspace> I also need the time to go and buy one
[15:36] <voidspace> maybe tomorrow during the day as I can work late tomorrow
[15:36] <wwitzel3> if only there was some way you could just order one online and it would arrive at your home
[15:36] <voidspace> wwitzel3: yeah, because telecoms company don't *deliberately* make that shit confusing to buy online
[15:36] <ericsnow> wwitzel3, voidspace: :)
[15:36] <wwitzel3> voidspace: good point :)
[15:36] <voidspace> wwitzel3: plus, if I order it today it will probably arrive just after we've left for France on Saturday morrning
[15:37] <voidspace> wwitzel3: I did look online and the contract details available were either "too short to be useful" or "too long to be humanly possible to read"
[15:39] <wwitzel3> perrito666, natefinch: standup?
[15:39] <wwitzel3> voidspace: I guess you too :P
[15:39] <voidspace> heh, ok
[15:45] <natefinch> yep
[15:49] <voidspace> jam: wallyworld: I've pushed changes to the backup-download PR
[15:49] <voidspace> https://github.com/juju/juju/pull/114/files
[15:55] <voidspace> ah, now I have internet I see I got an LGTM
[15:55] <voidspace> wallyworld: thanks!
[15:55] <jcw4> voidspace: internet is such a sweet thing
[15:55] <voidspace> jcw4: heh, it certainly is :-)
[15:57] <tasdomas> where does state/apiserver/client fit into the go stack described in doc/api.txt ?
[16:00] <jcw4> fwereade: ^^ (or anyone else with state knowledge since I believe fwereade is under the weather today)
[16:09] <mgz> tasdomas: it's the api server side for client-oriented api calls
[16:10] <mgz> doc/api.txt is all future-tense - I don;t think it's ever been updated from when the api actually got implemented, so probably isn't as clear as it could be
[16:10] <tasdomas> mgz, and state/api is the client-side api end-point?
[16:10] <mgz> yup, that's it
[16:17] <tasdomas> mgz, I don't see any tests that call the state/apiserver/client calls directly (they seem to all test that via state/api) - am I missing something?
[16:19] <mgz> tasdomas: the client package there is a little different to all the other apiserver bits, they get tested through the client side only, not at both end
[16:21] <tasdomas> mgz, right - that makes things a bit clearer, thanks
[16:21] <tasdomas> mgz, a testing-related question, if I can bother you with it
[16:22] <tasdomas> mgz, in https://github.com/juju/juju/pull/115 I modify the EnsureAvailability call to make it a bulk API call
[16:23] <perrito666> lunch bbl
[16:23] <tasdomas> mgz, is there a way to patch the EnvironTag value in the state in state/api ?
[16:24] <tasdomas> mgz, I want to add a test that sends an incorrect environment tag, but since it's a private state property, I think it's not patchable
[16:29] <mgz> tasdomas: can you not do it via state/conn_test.go ? that has some ability to do fiddling under the coversd
[16:29] <mgz> dimitern may have better ideas on how you want to check that something is a bulk call, if he's around
[16:30] <tasdomas> mgz, thanks - I'll pick it up with dimitern tomorrow then (EOD)
[16:36] <jam1> tasdomas: api.Open takes an api.Info object which specifies the EnvironTag to pass
[16:37] <jam1> though Open should fail if you pass an invalid one
[16:37] <jam1> you're trying to override it after the fact?
[16:37] <jam1> tasdomas: if its a state/api test, you could put a helper in state/api/export_test that let you explicitly poke at the internals
[17:02]  * natefinch is finally having breakfast
[17:02] <jcw4> natefinch: you on the west coast today?
[17:02] <jcw4> ;)
[17:02] <natefinch> heh nope.  Just busy morning
[17:03] <perrito666> man I wish I understood flight reservation sofware encoding
[17:04] <jcw4> software encoding?
[17:06] <natefinch> The second best thing about having a sprint nearby is not having to do reservations and all that BS
[17:08] <perrito666> jcw4: they use this very old console soft
[17:08] <perrito666> like almost serial printer console old
[17:08] <jcw4> yeah?
[17:08] <perrito666> and each line of information is a fixed width columns set
[17:09] <perrito666> so, you get things like this as a result
[17:09] <perrito666> 1  *LA2422  H  05JUL  COR  LIM   0455  0700   E0/320
[17:09] <perrito666> now, I understand most of it :p
[17:09] <perrito666> but the * in front of LA is amistery
[17:09] <perrito666> the H too
[17:09] <jcw4> I think it means you're on a TSA watchlist
[17:09] <perrito666> and the ocasional numbers in a column that is not there is also a mistery
[17:10] <jcw4> I'm always interested in those codes too... they sometimes give information that isn't published anywhere else
[17:11] <perrito666> jcw4: I am mostly interested because I am trying to decipher if I want or not that flight
[17:11] <perrito666> jcw4: you can make a tourism operator course, they teach you to use that thing
[17:12] <natefinch> can't you just use kayak.com like everyone else? :)
[17:12] <perrito666> everything about tourism is so 80s
[17:12] <jcw4> haha
[17:12] <perrito666> I use despegar.com
[17:12] <perrito666> natefinch: but this is the email sent to me by the tourism guys :) which assume I also did the software course
[17:13] <perrito666> same happens to me when I go to a travel agency for vacations, they print me this monospaced font paper and give it to me :p
[17:14] <jcw4> perrito666: well, good luck with that.
[17:16] <natefinch> perrito666: just look up the flight number online
[17:17] <perrito666> natefinch: yup did that, seems normal :p
[17:25] <voidspace> natefinch: I've found out that they're tinkering with the internet connection for the village
[17:25] <voidspace> natefinch: adding "new boxes", so it will be ropey for at least another week
[17:26] <voidspace> natefinch: and then hopefully better
[17:26] <voidspace> natefinch: but I'm away next week *anyway*
[17:26] <voidspace> natefinch: so hopefully all good when I get back
[17:26] <voidspace> good to have an answer anyway
[17:29] <ericsnow> voidspace: yay
[17:29] <ericsnow> voidspace: it wasn't my fault ;)
[17:30] <voidspace> ericsnow: hah, I'm sure karmically it's still your fault somehow...
[17:30] <ericsnow> voidspace: no doubt :)
[17:33] <natefinch> voidspace: yeah, nice to know why it's happening, and nice to know it'll be done eventually
[17:34] <voidspace> yep
[17:34] <perrito666> voidspace: they are changing the 6eths switch for an 8eths one :p
[17:36] <voidspace> perrito666: I don't know what that means
[17:36] <voidspace> but it sounds good
[17:37] <perrito666> voidspace: I was implying that the internet of your whole village was held by a 6port switch :p
[17:37] <voidspace> perrito666: heh, I doubt we even get six...
[17:38] <perrito666> when I moved to my current city (capital of this state) one of the largest providers of dsl had such bad config that we where on a LAN I could fetch things from the shared MyDocuments folders from every other client on my subnet
[17:56] <perrito666> sinzui: any luck running in another provider?
[17:58] <sinzui> perrito666, I just got more RAM for HP. I will move the functional-ha-backup-restore to HP and hope for a pass
[17:58] <perrito666> sinzui: I am having hell running on ec2
[17:58] <sinzui> perrito666, I think trusty is more brittle than precise on ec2
[17:59] <sinzui> I moved those tests back to precise
[17:59] <perrito666> I get a machine to create the state machine but it blows when trying to create the cs:ubuntu one
[18:01] <voidspace> right, BBQ time!
[18:01] <voidspace> EOD
[18:01] <voidspace> g'night all - see you tomorrow
[18:01] <natefinch> night voidspace
[18:02] <perrito666> nite voidspace
[18:02] <voidspace> o/
[18:06] <sinzui> perrito666, CI isabout 2.5 hour from running the failing test with tip.   Is that a correct summary?
[19:06] <natefinch> ericsnow: or were you thinking something like juju bootstrap, juju upload-backup, juju restore?
[19:07] <ericsnow> natefinch: I'm not sure what the use case is for more than one command
[19:07] <ericsnow> natefinch: I was talking more about the API client side of things
[19:07] <natefinch> ericsnow: ahh
[19:08] <natefinch> ericsnow: it seems like all we really need is an http API called "Restore" that can take a file.  If it can restore, it does.  If it can't it says so.
[19:09] <ericsnow> natefinch: that makes sense to me for the immediate term
[19:09] <ericsnow> natefinch: and it may be all we need long-term too :)
[19:09] <natefinch> ericsnow: YAGNI :)
[19:09] <ericsnow> natefinch: exactly!
[19:10] <sparkiegeek> if I have two units of the same subordinate service "hulk-smashed" onto a single machine, will I get hooks being run concurrently? (e.g. unit/0 hookX and unit/1 hookX being run at the same time)?
[19:10] <sparkiegeek> or does juju guarantee that they'll be serialised
[19:11] <natefinch> sparkiegeek: juju guarantees nothing if you have hulk smashed
[19:11] <sparkiegeek> natefinch: so two agents = operate independently?
[19:12] <natefinch> sparkiegeek: that being said, I'm not sure of the current behavior right now, it's possible they'll be serialized.
[19:12] <ericsnow> natefinch: nice :)
[19:12] <sparkiegeek> natefinch: anecdotal evidence suggests they *are* but I'm trying to hunt down a race condition which might be caused if they're not :)
[19:13] <sparkiegeek> (1.19.3 FWIW)
[19:25] <natefinch> marcoceppi: do you know if two units of the same subordinate service will have their hooks serialized?  or is it possible they'll get run at the same time?  I don't actually know how hooks are serialized?
[19:25] <natefinch> sorry... ^^ if they are hulk smashed on the same machine
[19:26] <marcoceppi> wow, hulk smashing the same subordinate on a machine twice, sounds like someone is asking for it
[19:26] <natefinch> basically what I said
[19:26] <marcoceppi> natefinch: afaik, it's serialized at the unit level, not the service level, so you could probably have two hooks on a unit running simultaneously
[19:27] <marcoceppi> I'd totally chaulk this up to "it's working as designed and you're wrong"
[19:31] <sparkiegeek> marcoceppi: FWIW I was asking what the design/behaviour was, not for a change :P
[19:32] <marcoceppi> well, this is my understanding, I've not confirmed this
[19:32] <marcoceppi> but it should jsut follow normal unit event dispatching, there's no special case for juju and events esp wrt hulksmashing
[19:33] <marcoceppi> I should also mention IANACD
[19:33] <natefinch> haha
[19:33] <sparkiegeek> marcoceppi: noted :)
[19:33] <sparkiegeek> it *seems* like events are serialised
[19:34] <sparkiegeek> I was hoping to shortcut lots of testing by asking you guys :)
[19:35] <marcoceppi> I'm under the impression they are serialized on a single unit basis and not nessiarily per service. I could be completely wrong though
[19:42] <sparkiegeek> marcoceppi: thanks. That was my assumption too but logs suggest that they are serialised. Ho hum
[19:45] <sinzui> natefinch, We have a ppc64el/gccgo regression https://bugs.launchpad.net/juju-core/+bug/1331744
[19:45] <_mup_> Bug #1331744: panic: reflect: Call of unexported method ppc64el/gccgo unit tests <ci> <gccgo> <ppc64el> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1331744>
[19:45] <sinzui> ^ we may need to wait for wallyworld or Dave to wake up
[19:50] <natefinch> sinzui: weird
[19:55] <natefinch> sinzui: that is some unfortunately gnarly code
[19:57] <natefinch> jam1 or jam2 will likely have a better understanding of it, I think.
[20:00] <jam2> natefinch: it is likely soemthing funny with the api versioning stuff, but I'm about to fall asleep. I assigned it to myself, but if wallyworld or someone else wakes up to it first, they are welcome to look at it.
[20:01] <natefinch> jam2: ha, yeah, pretty late there.  OK
[20:03] <perrito666> sinzui: back, the build failed for a reason I dont understand
[20:07] <sinzui> perrito666, It failed because HA wasn't achieved in 15 minutes or was it 20 minutes
[20:09] <perrito666> sinzui:  did you see that it marked 3 machines just when it died?
[20:09] <sinzui> I did
[20:10] <sinzui> perrito666, I was going to let CI just play the test with the current build...
[20:10] <perrito666> something interesting I noticed the other day, I sshd into the machine as it was doing the ha sync and the load was on the skyes
[20:11] <sinzui> perrito666, but there is a gccgo problem with the current build...the arm64 builder took 3 hours.
[20:14] <perrito666> man, there is a huge load of bad karma with this issue
[20:16] <sinzui> I am going to reboot the arm64 machine. I had to do that with the ppc64el machine because all the memory and disk was used up
[20:16]  * perrito666 tries to reproduce the test by hand
[20:17] <sinzui> or not. The machine says it is healthy now
[20:17] <sinzui> perrito666, I will run the test again...I want to extend the time to get to HA
[20:18] <perrito666> give it time, I am curious to know if the test goes trough regardless of the lag of HA, to see if I can finally figure out where is the problem
[20:19] <perrito666> I read the commits around the first failures, there is no indication of anything that goes even near restore
[21:01] <perrito666> sinzui: my local test failed, it restored the machine but status reports the old info
[21:04] <sinzui> :/
[21:04] <perrito666> is, as if the mongo query runs but takes no effect
[21:05] <perrito666> but when I go to the shell and do it by hand it works
[21:05] <perrito666> mm strange
[21:07] <ericsnow> perrito666: perhaps a difference in shell environment?
[21:08] <perrito666> yes, that is my current line of thought, mongo's client man page says that there might be differences between what is available to --eval and in the actual shell
[21:08] <perrito666> perhaps there was a version change in mongo that affected us
[21:08] <perrito666> Ill try something
[21:25] <thumper> morning folks
[21:28] <thumper> omg, so many emails...
[21:28]  * thumper needs to get some tweaking on pull request emails.
[21:51] <lifeless> thumper: heh, I read that as twerking on pull request emails
[21:51] <waigani> morning thumper
[21:51] <thumper> lifeless: ha
[21:53] <thumper> morning waigani
[22:00] <mattyw> thumper, morning
[22:23] <alexisb> mattyw, you must be working the late shift
[22:24] <mattyw> alexisb, I'm hoping to grab thumper to ask a couple of questions, I'm going to make up for it tomorrow morning :)
[22:24] <thumper> mattyw: hey, otp with fwereade
[22:24] <alexisb> :)
[22:24] <mattyw> thumper, no problem, ping when you have 5 minutes
[22:35] <perrito666> large threads that include hazmat and fwereade should arrive to my kindle instead of my mailbox :p
[22:36] <fwereade> perrito666, oh, I can get *much* worse if it comes to it ;p
[22:40] <perrito666> aghh juju robustness is biting me
[22:40] <perrito666> I edit out any possible reference to old apiservers from the machine and it comes back
[22:52] <thumper> mattyw: I have 5 minutes
[22:53] <thumper> perrito666: hahaha
[22:53] <mattyw> thumper, ok cool - I'll just type questions then if that's ok?
[22:53] <thumper> sure
[22:54] <mattyw> thumper, the change-password command, at the moment entering an empty password (or just calling juju change-password) will cause a random one to get generated, should I change this to expect the user to input the password, and have a flag for generating a password?
[22:54] <thumper> mattyw: hmm...
[22:54] <thumper> mattyw: to be honest, not quite sure...
[22:55] <thumper> mattyw: I have been spending a lot of time looking at the whole identity vs. user issue
[22:55] <thumper> mattyw: and all the stuff we have now is likely to change :-)
[22:55] <mattyw> thumper, that's fine, change is good
[22:55] <thumper> mattyw: we have two main reasons for change password
[22:55] <thumper> 1) as a user I'd like to change my password to something meaningful to me (or in my lastpass)
[22:56] <thumper> 2) as an admin, I want to reset another user's password
[22:56] <thumper> the problem is right now, everyone is an admin
[22:56] <thumper> as we don't have the permissions in there yet
[22:57] <thumper> so, for 1) we need to think "why is the user asking?"
[22:57] <thumper> perhaps we should always prompt, but accept empty to mean "please generate one for me"
[22:57] <mattyw> having a prompt means the user's password doesn't appear in the bash history - but then again the password is stored in plain text in the jenv anyway
[22:58] <thumper> sure, for now
[22:58] <thumper> I think prompting is the correct approach
[22:59] <mattyw> But my next question was going to be: At the moment the setpassword call in the apiserver only allows you to change the password for the user you're logged in as
[22:59] <thumper> right...
[22:59] <thumper> which doesn't allow use-case 2
[22:59] <mattyw> and I wonder if that's a good approach or not - I will have to change.... - yeah exactly
[22:59] <mattyw> change-password and access-file feel like very similar commands to me
[23:00] <mattyw> thumper, isn't your standup coming up - shall I join it?
[23:00] <thumper> I think... that we should make change-password a bulk call where is specifies a list of users/passwords
[23:00] <thumper> and worry about permissions later
[23:00] <thumper> mattyw: if you like


[11:37] <tijara> Afdal: yep, it's over for IRC
[11:38] <Afdal> N-never!
 @kc2bez your new profil photo looks good
[16:20] <Munsko> Hello. I noticed that sometimes, the "discover" app dont recognize some .debs that i installed, but i can confirm that they are installed because i can run them
[16:21] <Munsko> Is this normal or should i create a topic on discourse/launchpad?
[16:22] <Munsko> Also i want to know if "discover" and "q-apt .deb installer" are independent things or they are "linked" someway
[22:05] <cris_> hi
[22:05] <cris_> i am lost here
[22:06] <cris_> where are you from
[23:50] <guiverc> Would a 20.04 user see the message "failed to execute child process lxsession-default directory.."  (seems like LXDE to me)?
[23:52] <Munsko> Maybe its 18.04
[23:52] <Munsko> LXDE was 18.04 desk if im not wrong
[23:52] <Munsko> And lxsession dont come installed by default on Lubuntu 20.04(just checked it)
[23:53] <guiverc> yep, that or the user has done strange things to their system.. I'm doing a fgrep of a qa-install for check..
[23:53] <Munsko> (We have lxqt-session
[23:53] <guiverc> thanks Munsko
[23:53] <Munsko> np :)


[12:04]  * MacSlow -> lunch
[15:20] <mac_v> bratsche: hi.. you around?
[15:20] <mac_v> right now xsplash , overrides usplash and doesnt display the processes which are loading during boot[the ones which appear on removing the "quiet" from the kernel line] , is there any way to view them with xsplash?
[15:22] <bratsche> mac_v: Oh, where it says like "now starting foo"?
[15:23] <mac_v> yeah... the starting xyz .... OK/failed
[15:24] <bratsche> mac_v: No, xsplash won't do that right now.
[15:24] <mac_v> for the final version it sounds good , but since we are testing only way to check , of anything has failed , is going back to logs
[15:24] <mac_v> oh :(
[15:24] <mac_v> bratsche: any future plans?
[15:25] <mac_v> for karmic+1 atleast ;)
[15:25] <bratsche> I'm not sure that it will ever be in xsplash, to be honest.  I think Mark and the design team want to move in the opposite direction.  A typical user doesn't know wtf dbus or avahi is, for example.
[15:26] <mac_v> yeah , the basic idea is good
[15:26] <bratsche> mac_v: For Karmic+1 the major feature to be added was going to be an OS switcher, so if you're in the middle of booting into Ubuntu then you could decide that you really wanted to boot into something else and you can just do it from there.
[15:26] <mac_v> bratsche: BUT , aernt we reducing features , by removing that option
[15:27] <bratsche> mac_v: You mean the feature to display what part of the system is starting up?
[15:27] <mac_v> hehe , yeah ;)
[15:28] <bratsche> mac_v: Maybe.  But I'm not the person who decides how it's supposed to work.  My job is to implement what Mark and the design team tell me to implement. ;)
[15:28] <mac_v> ;p
[15:29] <bratsche> I expect they might argue that it's okay to drop features if it makes the system more usable or less cryptic looking for their target audience.
[15:29] <mac_v> bratsche: a side effect is... the shutdown will display the processes and not the boot , [since xsplash works only during boot]... for a recent alpha bug , i noticed that the disks were not unmounting on shutdown , hence i could do it
[15:30] <mac_v> BTW , why no xslpash for shutdown?
[15:30] <mac_v> splash*
[15:30] <bratsche> I've heard it suggested that we may add it.
[15:31] <mac_v> bratsche: you mean the xsplash for shutdown? ^ .. add it for karmic or for +1
[15:32] <bratsche> It's too late for Karmic, but maybe in +1
[15:32] <mac_v> :)
[15:33] <mac_v> bratsche: thanks for the info... do poke sabdfl for *not* dropping the option ;)
[15:33] <bratsche> I'll let you do that.  I'm not eager to add more work for myself in xsplash. :)
[15:34] <mac_v> hehe  ,ok  ;)
[15:34] <bratsche> Karmic+1 I'm hoping to be focusing on gtk+ more.
[15:34]  * mac_v waiting for rbga too
[15:40] <mac_v> !grub2
[15:40] <ubot4> GRUB2 is the default Ubuntu boot manager in Karmic. For more information on GRUB2 please refer to https://wiki.ubuntu.com/Grub2
[15:45] <davidbarth> mac_v: displaying the name of the system that is starting sounds like a good idea yes; for karmic+1 though; not sure if we would list the version of the kernel that is used however, that would be quite cryptic for users, except if they explicitely selected a non-default kernel
[16:00] <mac_v> davidbarth: you meant "name of the system *process*" , right? i was mentioning about this option > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" , removing the "quiet" shows the messages during boot... if so great :) ....  Interesting idea though, about not showing the kernel versions...how are you planning to replace the kernel numbers that are listed in grub?
[16:02] <davidbarth> mac_v: no real plan yet; that's something to think about; but the metadata in grub should contain enough information
[16:06] <mac_v> nice idea though ,looking forward :)
[17:44] <djsiegel> DanRabbit1, ping
[21:39] <MDC1> DanRabbit, you don't happen to know where to get the background from this screenshot? http://lh3.ggpht.com/_FJH0hYZmVtc/SrEl1vZzvGI/AAAAAAAAC1s/Me2At5_OJM8/s1600-h/dust-0917-screenshot-preview%5B4%5D.jpg
[22:04] <DanRabbit> MDC1: no :( sorry
[22:05] <MDC1> DanRabiit, np, did you get my mail?
[22:05] <mac_v> DanRabbit: heya ;)
[22:05] <DanRabbit> hey there
[22:05] <DanRabbit> MDC1: which mail?
[22:06] <MDC1> hmm.. maybe it wasn't you - sorry ;)
[22:06] <mac_v> DanRabbit: which version of the user-away do you  like ?
[22:06] <mac_v> its in the 22px folder
[22:06] <DanRabbit> Haven't checked yet :/
[22:06] <DanRabbit> I'm about to leave for work in like 10 mins
[22:07] <mac_v> DanRabbit: hehe , yeah David was in here asking for you told him , you are super busy :)
[22:07] <MDC1> and i'm about to go to bed in 2 sec :-)
[22:07] <DanRabbit> haha
[22:08] <DanRabbit> MDC1: What's your email addresS?
[22:09] <MDC1><EMAIL_ADDRESS>[22:11] <DanRabbit> OH
[22:11] <DanRabbit> lol
[22:11] <DanRabbit> Id didn't realize it was you!
[22:11] <DanRabbit> I'm actually replying to your email right now ;)
[22:13] <MDC1> i'd figured it was you but wasn't absolutly sure ;-) i'm off to bed.. see ya!
[22:14] <DanRabbit> night
[22:18] <DanRabbit> Alright I'm off again :/
[22:18] <DanRabbit> bye everyone


[00:29] <OvenWerks> YoJimmy: this is not the best place to ask :)
[00:30] <OvenWerks> YoJimmy: #opensourcemusicians or #ardour have lots of people with opinions
[01:43] <studio-user244> hi


[04:13] <psusi> bug #668050 is just a somewhat insulting rant about their system becoming unresponsive while greatly overtaxing ram... my inclination is to close it with a comment about bugs are not a place to rant... how do you think this could be handled better?
[04:13] <ubot2> Launchpad bug 668050 in ubuntu "Desktop completely unresponsive on low memory due to stupid swapping. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/668050
[04:19] <psusi> anyone?
[04:23] <RedSingularity> psusi:  I would ask him to file reports for each issue and try to work them out one by one.  Putting all you "bugs" into one report is no good.
[04:23] <RedSingularity> your*
[04:25] <RedSingularity> cjohnston:  you available at the moment?
[04:29] <RedSingularity> Dr_Who:  Available at the moment?
[04:29] <Dr_Who> yes
[04:30] <RedSingularity> Can you mark a "triaged" for me?
[04:30] <Dr_Who> well guess depends .. what's the bug # ?
[04:31] <Dr_Who> as you might guess don't like to mark things just to mark things
[04:31] <RedSingularity> bug 664265 It has a few "confirmations" from other users at the bottom as well.  :)
[04:31] <ubot2> Launchpad bug 664265 in xserver-xorg-video-intel (Ubuntu) "Can't play flash videos full screen on firefox and google chrome with intel driver and compiz (affects: 3) (heat: 22)" [Low,Confirmed] https://launchpad.net/bugs/664265
[04:31] <RedSingularity> Dr_Who:  no no i understand :)
[04:54] <psusi> RedSingularity, huh?  I only see one complaint: that the system becomes unresponsive when thrashing memory
[04:56] <RedSingularity> psusi:  Looked like he had a lot of complaining but i really didnt read it through.  If thats the case and it seems like a real "bug" you could ask him to file a more "mature" report.....
[04:57] <RedSingularity> psusi:  I know i wouldnt work on a "rant" and send it to the developers that way.
[04:57] <psusi> oh I don't think it is suitable to be triaged and worked on... I'm just wondering what the most polite way to close it is ;)
[04:58] <RedSingularity> psusi:  ohhh, heh good question ;)
[07:43] <game2> hi, can a bug-controller here please revert bug #580006 to Triaged ?
[07:43] <ubot2> Launchpad bug 580006 in linux (Ubuntu) "Headphone jack sense missing on Realtek ALC269 (affects: 7) (dups: 1) (heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/580006
[09:39] <rusivi> Late comment on bug 668050 I've had the same problem in Windows w/ Matlab, as Matlab requires one to create large swap files (I had 20GB at one point). His rant, while impasse, does have merit.
[09:39] <ubot2> Launchpad bug 668050 in ubuntu "Desktop completely unresponsive on low memory due to stupid swapping. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/668050
[12:02] <cjohnston> RedSingularity: yes?
[12:52] <game2> hi, can a bug-controller here please revert bug #580006 to Triaged ?
[12:52] <ubot2> Launchpad bug 580006 in linux (Ubuntu) "Headphone jack sense missing on Realtek ALC269 (affects: 7) (dups: 1) (heat: 46)" [Medium,Confirmed] https://launchpad.net/bugs/580006
[13:17] <halvors> Hi
[13:17] <halvors> I have really problems with GDM.
[13:17] <halvors> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/668016
[13:17] <ubot2> Launchpad bug 668016 in gdm (Ubuntu) "Cannot use the default Ambiance theme when installed nvidia non-free driver. (affects: 1) (heat: 6)" [Undecided,New]
[13:17] <halvors> Reported this bug.
[13:22] <halvors> Someone can help me?
[13:22] <halvors> Out?
[13:53] <drcooper> need some guidance. There are a lots of "package failed to install/upgrade" bugs. How should I go about such bugs.
[14:04] <mortal> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/667336 <- how do I get additional info
[14:04] <ubot2> Launchpad bug 667336 in compiz (Ubuntu) "weird compiz crash, pointer on top of a long url in pidgin, compiz crashes (affects: 1) (heat: 6)" [Medium,Invalid]
[14:07] <halvors> Can anyone look at this bug?
[14:07] <halvors> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/668016
[14:07] <ubot2> Launchpad bug 668016 in gdm (Ubuntu) "Cannot use the default Ambiance theme when installed nvidia non-free driver. (affects: 1) (heat: 6)" [Undecided,New]
[14:10] <drcooper> halvors: i could reproduce it
[14:10] <drcooper> halvors: so i confirmed the bug
[14:13] <halvors> drcooper: What did you mean?
[14:14] <drcooper> halvors: when you hover mouse pointer over a looong link in pidgin, compiz crashes
[14:14] <drcooper> halvors: it really does
[14:14] <halvors> What?
[14:14] <halvors> I am talking about this bug...
[14:16] <drcooper> halvors: sorry i am talking of bug 667336
[14:16] <ubot2> Launchpad bug 667336 in compiz (Ubuntu) "weird compiz crash, pointer on top of a long url in pidgin, compiz crashes (affects: 2) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/667336
[14:16] <halvors> ok
[14:16] <drcooper> someone else asked about it
[14:16] <drcooper> sorry
[14:17] <halvors> ok
[14:17] <halvors> But can anyone help me with the 668016 bug?
[14:45] <elleuca> anyone with 10.10 and iPod touch that could confirm this?
[14:45] <elleuca> https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/668336
[14:45] <ubot2> Launchpad bug 668336 in rhythmbox (Ubuntu) "[REGRESSION] Can't reproduce MP3 transferred on iPod Touch (affects: 1) (heat: 6)" [Undecided,New]
[15:16] <geekosopher> time to add 'lucid2maverick' in Bugs/Tags wiki page?
[17:19] <j_baer> I am experiencing server errors on the Ubuntu wiki. I need some guidance on how to report this bug.
[17:19] <micahg> j_baer: https://edge.launchpad.net/ubuntu-website or #ubuntu-website
[17:20] <j_baer> Would "website" be wik?
[17:21] <micahg> j_baer: yes
[17:22] <j_baer> got-it thanks!
[19:49] <geekosopher> can bug 668153 be marked as duplicate of bug 668154 or vice versa?
[19:49] <ubot2> Launchpad bug 668153 in ubuntu "package libgnome-vfs2.0-cil 2.20.0-2ubuntu3 failed to install/upgrade: (affects: 1) (heat: 8)" [Undecided,Incomplete] https://launchpad.net/bugs/668153
[19:49] <ubot2> Launchpad bug 668154 in gnash (Ubuntu) "package libmono-system-runtime2.0-cil (not installed) failed to install/upgrade: (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/668154
[19:51] <paultag> geekosopher, they're filed by the same person -- it could be
[19:51] <geekosopher> both the bugs are reported by same person, and the error logs are almost identical. in 668154 the reporter has steps to recreate it
[19:51] <paultag> geekosopher, look through the logs, if it fails because of the common dep they're dupes
[19:51] <paultag> sec
[19:52] <paultag> geekosopher, it should be one bug against swfdec-mozilla   <-- if what he's saying is true
[19:52] <paultag> Let me check the rdeps
[19:52] <geekosopher> yes, jibel already marked 668154 against gnash
[19:53] <paultag> so he did
[19:53] <paultag> they look related geekosopher
[19:54] <paultag>  no package named `epiphany-browser' is installed, cannot configure  <-- geekosopher that's from 668153
[19:54] <paultag> geekosopher, and since that's failing because of gnash, it's the same error
[19:54] <paultag> rather, if that's failing
[19:54] <paultag> geekosopher, yeah, I'd combine them
[19:54] <paultag> geekosopher, great catch, great insight
[19:55] <geekosopher> so I will mark 668153 as duplicate of 668154
[19:55] <paultag> Yeah
[19:55] <geekosopher> paultag: thanks... was trying to triage both of them since morning
[19:55] <paultag> geekosopher, usually the first bug would be the "main" one -- but the second one looks better
[19:55] <paultag> geekosopher, so I'd mark the first as a dupe of the second to cut down on spam to the gnash guys
[19:56] <geekosopher> paultag: ok... here i go
[19:58] <geekosopher> paultag: is there a need to keep the lucid2maverick tag? I added it when marking the bug against update-manager
[19:58] <geekosopher> sorry hardy2lucid
[19:59] <paultag> geekosopher, let the gnash guys sort it out :)
[19:59] <geekosopher> ok
[19:59] <paultag> geekosopher, it's filed against their project, it's theirs now -- you've done your work
[19:59] <geekosopher> :)
[20:00] <paultag> :)
[20:00] <paultag> geekosopher, well done
[20:00] <paultag> geekosopher, keep rocken :)
[20:00] <geekosopher> always wanted to do one bug right ;)
[20:00] <paultag> :)
[20:01] <paultag> heyya sense
[20:01] <sense> hi paultag
[20:01] <paultag> sense, how's life?
[20:02] <sense> paultag: At the moment very good, with ice cream and sun in Orlando.
[20:02] <paultag> sense, I'm super jealous. Yell at Jorge for me, please. No reason :)
[20:02] <geekosopher> i am not able to see the 'add tag' links (using firefox-lp-improvements). is it only me or everyone?
[20:02] <sense> paultag :)
[20:03] <paultag> sense, it's been super quiet since everyone's at UDS. I don't know what to do with myself
[20:04] <sense> paultag: Awww. Well, there are enough bugs to triage if you're bored.
[20:05] <paultag> sense, yeah, I picked up a few just for kicks. I ended up writing a pretty cool app for the LoCo Council. It let's us do our work from the CLI :)
[20:05] <sense> yay
[20:05] <geekosopher> paultag: hehe I thought I was the only one feeling lonely ;)
[20:05] <paultag> heh
[20:07] <paultag> Anywho. Back to cleaning the house. Long overdue. After all, it makes no sense to keep a house dirty
[20:07] <paultag> ( see what I did there )
[20:07] <paultag> OK, later. Much love.
[20:07] <sense> I see it!
[20:07] <paultag> :)
[20:07] <sense> Have fun with cleaning!
[20:07] <paultag> oh gee thanks :)
[20:07] <sense> enjoy the dust
[20:19] <roberts> Has anybody *ever* had a useful response from having reported a bug to Canonical via their launchpad system?
[20:22] <Nafallo> yes
[20:22] <roberts> Care to be more specific?
[20:23] <roberts> I submitted bug #660864 over a week ago, which is a critical network driver bug.  No response, not even assigned yet.
[20:23] <ubot2> Launchpad bug 660864 in linux-restricted-modules-2.6.15 (Ubuntu) "Ubuntu 10.10 Atheros AR9285 Wireless disconnects (affects: 3) (heat: 279)" [Undecided,New] https://launchpad.net/bugs/660864
[20:24] <Nafallo> not sure how I could be. I've been involved with Ubuntu since Sept. 2004 and I've had quite a lot of my bugs fixed.
[20:25] <roberts> I've been involved with Linux since Slackware v1 starting around 1993.
[20:25] <Pici> The bug description states that you're running 2.6.35, but its filed against the 2.6.15 package.
[20:26] <roberts> I've got code in one of the Redhat kernels.  Not a noob, in other words.  Launchpad seems completely broken.
[20:27] <roberts> Getting  filed against the 2.6.15 package was done automatically by launchpad when I created the bug report.
[20:28] <roberts> I'm also a write for Linux Journal, and have published part one of a story about this particular bug:  http://www.linuxjournal.com/content/ubuntu-1010-maverick-meerkat-one-hit-one-miss
[20:29] <roberts> Part two, which chronicles my launchpad bug reporting experience so far should come out soon.
[20:30] <roberts> I also don't type very well:  I'm a *writer* ...
[20:30] <roberts> :)
[20:33] <yofel> launchpad should never just choose a package for you but "I don't know" should be the default
[20:34] <roberts> I agree, that is how launchpad should respond.
[20:34] <simar> vish, hi
[20:34] <yofel> roberts: could you file a new bug with 'ubuntu-bug linux' after you had the issue again? That will add most of the information needed by the kernel team to the report too
[20:34] <simar> vish, does this bug appears for you also https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/668497
[20:34] <ubot2> Launchpad bug 668497 in xserver-xorg-input-synaptics (Ubuntu) "Cursor stucks temporarily when using certain key cominations. (affects: 1) (heat: 6)" [Undecided,New]
[20:34] <simar> vish, I guess it should be classified as a papercut
[20:36] <roberts> yofel: Using launchpad?
[20:36] <vish> simar: yea, i have that bug, there is another dup as well
[20:36] <simar> vish, oh
[20:36] <vish> simar: i think it is in 'ubuntu' and not associated with a package..
[20:36] <simar> vish, its a papercut i suppose
[20:37] <vish> simar: any idea what is causing it?
[20:37] <yofel> roberts: first run the command on your system and apport will open the launchpad bug filing page after you follow the instructions
[20:37] <vish> simar: my guess is it is not a simple change/fix
[20:37] <vish> yofel: are you at the UDS?
[20:37] <yofel> vish: no, no time
[20:37] <vish> hmm.. ok..
[20:37] <simar> vish, Surely the xserver-xorg-input-synaptics driver ... posiibly
[20:38] <simar> vish, i will try removing it and then see weather the bug appears again or not
[20:38] <roberts> yoful: Ok.
[20:38] <paultag> roberts, you're also not filing a bug to Canonical directly
[20:38] <paultag> roberts, you're sending that to the Kernel team, which has Canonical guys on it ( but not as a pre-req )
[20:39] <simar> vish, The bug is occurring for everyone so I though it should be a papercut ... it must be removed to improve user experience..
[20:40] <paultag> roberts, can you please add information to the bug, right now it's incomplete
[20:40] <paultag> roberts, man apport-bug
[20:40] <roberts> paultag: That is as it should be.  The bug almost certainly lies in the Atheros driver kernel module.  But I got to the launchpad link via the Ubuntu.com home page.
[20:40] <paultag> roberts, you can have it add to it, if you would like
[20:40] <paultag> roberts, I'm not sure we maintain that in Ubuntu -- have you also notified upstream, or talked with #ubuntu-kernel ?
[20:41] <roberts> paultag: And this is a 10.10 release QA issue, more than anything else.
[20:41] <roberts> This particular bug has been in and out of Ubuntu releases as far back as 7.04, apparenly.
[20:41] <paultag> roberts, you need to add more information, if this is that big of an issue, talk with the kernel team, and also talk with the vendor of the module, so they can get a fix out and we can import it -- having contributed to the kernel before you should know the workflow :)
[20:42] <paultag> roberts, #ubuntu-kernel, or the mailing lists
[20:43] <roberts> paultag: Thanks, that's why I came here - to get fresh leads after launchpad dead-ended.
[20:43] <paultag> roberts, roger. Let's head over to kernrel
[20:43] <paultag> kernel *
[20:44] <roberts> ok, on my way paultag
[23:28] <BUGabundo> evening
[23:33] <kklimonda_> hey BUGabundo
[23:33] <BUGabundo> olá kklimonda_


[02:12] <infinity> plars: (If there's anyone you can hand off those regression-testing tasks to, I'd like to be able to release those kernels tonight to clear the road for more, if possible)
[02:13] <plars> infinity: good timing, one of them *just* finished, the other is still in progress
[02:13] <infinity> plars: Kay.  Those would be the LTS ones?  What's the continuing story with ti-omap4?
[02:13] <plars> infinity: the omap4 one was done much earlier, but we had a couple of failures
[02:14] <infinity> Were all the failures just whacky timing issues?  Reproducible (or haven't had time for a second test run)?
[02:14] <plars> infinity: https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1181023 is the one that just finished
[02:14] <ubot2> Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress]
[02:14] <infinity> plars: Lovely.
[02:14] <plars> infinity: on omap, reproducible, two runs were done (they take 8+ hours each)
[02:15] <infinity> Hrm.  Curious.  Do you have output anywhere that I can try to digest?
[02:15] <plars> infinity: I can set it up with the previous kernel and run it there and see if we get the same result
[02:15] <infinity> Or that.
[02:15] <plars> if so, it wouldn't be a regression for sure
[02:15] <plars> infinity: but won't know anything until morning
[02:15] <plars> infinity: because it will take that long to run
[02:15] <infinity> Well, testing if it really is a regression would be good, but I'm also curious what the exact failures are.
[02:16] <plars> infinity: I can forward you the mail, one moment
[02:16] <infinity> (If we release everything except omap4, that won't hurt my feelings much either)
[02:17] <plars> infinity: sent
[02:20] <plars> infinity: because those other two were in parallel, this other one for quantal lts has a few hours to go because it was waiting on system. So far it has all passed though
[02:23] <infinity> Hrm, that log is curious.
[02:24] <infinity> Did you reboot between the first and second test run?
[02:24] <infinity> And does dmesg show anything weird?
[02:29] <plars> infinity: yes, I did reboot
[02:35] <plars> infinity: what was changed in this sru?
[02:39] <infinity> plars: Same as was changed on every other arch, if that's helpful. :P
[02:39] <infinity> (I'm looking now to see if there was anything ARM-specific and obviously scary)
[02:45] <plars> infinity: if it helps, the test description is only         '''ptrace allowed only on children or declared processes'''
[02:45] <plars> infinity: not horribly familiar with what these tests are trying to do though I'm afraid
[02:46] <plars> this is all stuff from the security team
[02:49] <infinity> plars: Yeah, I'm fairly sure I know what the test will be trying to do, but I'm not seeing any obvious reasons why it would be failing all of a sudden.
[02:49] <infinity> plars: I guess we'll wait on your results tomorrow, and if it's broken the same way, dig deeper.
[02:50] <plars> infinity: ok
[02:50] <plars> I'll get this set back up with the old kernel
[02:50] <infinity> plars: But the whole "tar no can read files, HALP" thing afterward, after a "sudo chown -R" points more the "maybe the system just got very confused and pooped itself" or similar. :P
[02:50] <infinity> s/more the/more to/
[02:52] <plars> infinity: the " Cannot stat: Permission denied" on the tar?
[02:52] <plars> infinity: I think that's just a missing sudo
[02:52] <infinity> plars: That makes little sense, given the line directly above.
[02:52] <plars> I've heard that's not new, so I'm ok with that one. It needs to be fixed though
[02:52] <infinity> plars: We explicitly chown all those files first.
[02:52] <infinity> ("We" being the test, I have nothing to do with this testsuite)
[02:53] <plars> infinity: well, as it stands on the system post-testing, the file doesn't exist
[02:53] <plars> yes, nor do I except to run it
[02:54] <plars> I'd like to dig into it a bit though
[04:45] <infinity> plars: ETA on lts-quantal?  Or did you abandon me for, like, having a life? :)
[04:46] <plars> no, just lying here in a puddle of drool
[04:47] <plars> infinity: it's running, I would have thought it to be done by now, there are only two systems left, but all the others look ok with the exception of a "out of space" error on one test that seems to have been seen before. Will check the lab set up to see if that's something like a too small disk, or just a buggy test not cleaning up previous messes
[04:49] <plars> ok, one just finished, one more left
[04:49] <infinity> \o/
[05:41] <plars> infinity: it's done, all good
[05:42] <infinity> plars: Yay, thanks.
[05:43] <plars> infinity: the panda (prev kernel) test is running too
[05:43] <plars> infinity: I'm going to go pass out now, good night
[09:01] <apw> chiluk, if you remove the build stamp from debian/stamps (it has build in its name) then in theory it 'continues' rather than restarting
[09:30] <NikTh> Hello.
[09:31] <NikTh> Question: Can someone tell me why the "~" character is not allowed in package name ? Read here another build failure of mine. https://launchpadlibrarian.net/140581585/buildlog_ubuntu-raring-amd64.linux_3.8.0-999~bfsbfq1_FAILEDTOBUILD.txt.gz
[09:31] <NikTh> I have already uploaded a package with this.. tilda (I think is the name) character inside and I had no problem. 3.8.0-21.32nikth1~bfsbfq1
[09:32] <NikTh> But this time I have a problem. I changed the ABI number because I didn't want users who add my PPA to upgrade the Official Ubuntu kernel with mine. I want to install (if they  want) a new kernel version manually.
[09:32] <apw> NikTh, indeed ~ is valid in a version not in a package name
[09:33] <apw> NikTh, that is a debian dpkg limitiation.  the kernel copies the version before the first - in the version into the binary package names, which means you cannot have a ~ before the first - in a version in the kernel packages
[09:37] <NikTh> apw: sorry but I need to understand this little better. This pacakge name is correct: 3.8.0-21.32nikth1~bfsbfq1. This package name isn't correct : linux_3.8.0-999~bfsbfq1 . What is the major difference here? And how can I set up a correct name that will indicates a completely different version.
[09:39] <NikTh> A completely different version so when a user add my PPA this will not upgrade the Official Ubuntu kernel. But if he/she want to install my kernel he/she must do it manually.
[09:40] <apw> it is actually everything to the first . following the first - that is copied out of the version into the package names
[09:40] <apw> therefore you cannot add a ~foo to the ABI number
[09:40] <apw> and anyhow 999~foo would sort higher than any version we would use
[09:40] <apw> so you would still upgrade the kernel regardless
[09:41] <apw> i cannot see why you would care if your package upgrades their kernel
[09:41] <apw> surely the point of adding you PPA would be to get the kernel and you
[09:41] <apw> want that to be automatic.  if the PPA has other things in it, you might really want
[09:41] <apw> a new PPA for this kernel alone
[09:41] <apw> you can have more than one iirc
[09:42] <NikTh> Ohh.. so I miss a dot here ? Correct name would be: 3.8.0-99.9.1~bfsbfq1 ?
[09:42] <NikTh> sorry I meant : 3.8.0-999.1~bfsbfq1
[09:44] <NikTh> apw: Yes, I don't have a problem to create a new PPA for this propose. I just consider this upgrade thing as .... dangerous ? Better would be to install new kernel Insead of upgrade the current one.
[09:50] <NikTh> I screwed up ABI number. And the builder thought this 999~bfsbfq1 was the ABI ? Am I correct ?
[11:27] <apw> NikTh, right, you cannot have a ~ in the name of a package, which includes the ABI number, which you set to 999~b...
[11:31] <NikTh> apw:  Do I must edit the debian/control file in order to create a new custom name ? For example the name : linux-nick 3.8.0-23.foo.32 I think is correct and also I will achieve my goal (not upgrade ubuntu's kernel), but of course it conflicts in debuild -S
[11:32] <apw> NikTh, in principle that would be ok, but in practice the kernle produces prodigious numbers of ancillary packages which also would need to be changed to prevent their kernel being replaced
[11:32] <apw> NikTh, using your own ABI number which is high like 500 or whatever (but without any text in it) would at least keep it separate and non-overlapping
[11:33] <apw> NikTh, _but_ it will be preferred over all of our kernels regardless of version
[11:39] <NikTh> apw: So if anyone add my PPA, he/she will install a custom-kernel and Ubuntu kernels will not be replaced, BUT he/she will not receive any updates in future from Ubuntu official kernel because of ABI number. No, this is not good (IMO). I want a separate package, a package that not effect or defect the original Ubuntu kernels  in any case.
[11:45] <apw> NikTh, anything you install which places a bootable kernel in a place where grub will use it, will trigger that kernel to either be so new it is always new, or so old it is never the default boot.
[11:46] <apw> NikTh, if you want people to have to select it each time in grub then you could make the ABI number much lower than all of ours, so they would get our updates; but that would mean they have to take action at the grub menu to get your kernel
[11:49] <NikTh> apw:  Is this allowed ? I mean to upload a version older than the current  ?
[11:49] <apw> nope, a ppa will reject that
[11:50] <apw> bah, what you want to do is hard
[12:21] <Adri2000> hi
[12:23] <Adri2000> the -22 kernel in raring has a regression over -21. it's not that critical (brightness control), but thought it might be useful to let you know
[12:23] <Adri2000> this is bug #1163720
[12:23] <ubot2> Launchpad bug 1163720 in Linux "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Incomplete] https://launchpad.net/bugs/1163720
[12:30] <maxb> Adri2000: The bug title disagrees with what you said (about versions)
[12:31] <apw> Adri2000, yeah what maxb said; if that bug is not your bug I would file a new one for your machine and add a comment mentioning the other one
[12:31] <apw> kamal, was the XPS13 the one your kernel was for ?
[12:36] <Adri2000> maxb, apw: see the last two comments of the bug report. it's the right bug, that was fixed at some point, and reappeared with the -22 kernel
[12:37] <maxb> If you're *strongly convinced* it's the same bug exactly, update the bug title - otherwise, consider whether it would be appropriate to open another bug report (mentioning the previous one, of course, but tracking the new occurrence)
[12:38] <maxb> Oh, actually, having just read the comment just before those two, *definitely* open a new bug
[12:40] <apw> Adri2000, it is good to get the exact h/w you have etc, in case there is a subtlty etc.
[12:40] <Adri2000> looking at the kernel changelog I see the the fix has been explicitely reverted: "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD", mentioning another bug report
[12:40] <apw> jsalisbury, ^^
[12:41] <Adri2000> yeah, I'll try to investigate a bit, but any more information would be welcome as well :)
[12:41] <apw> Adri2000, ahh ... then yes that is expected, and in that case it probabally should have been reopened when we reverted the patch
[12:41] <jsalisbury> apw, ack
[12:41] <apw> henrix, ^^
[12:41] <apw> jsalisbury, ta
[12:41] <jsalisbury> Adri2000, I'll take a look at the bug report
[12:42] <henrix> apw: looking
[12:43] <apw> henrix, it seems we reverted the fix explicitly but it is implied here the bug remained closed
[12:43] <henrix> apw: yep, looks like we need to either re-open or create a new bug.
[12:44] <henrix> apw: maybe its better to wait for kamal to be around, both bugs have been handled by him. lets see what are his thoughts on this
[12:45] <henrix> looks like the patch to fix the bug breaks something else
[12:59] <apw> henrix, yeah, when we revert we need to remember to move things back from Fix Released so they do not get lost ... shame LP has no syntax for it
[13:00] <henrix> apw: yep, that would help. i'll move it back to Confirmed and ping kamal on this
[13:00] <apw> henrix, great, that seems safest
[14:44] <rsalveti> rtg: were you able to test the grouper kernel?
[14:44] <rsalveti> that's the only one pending still
[14:45] <rtg> I have not yet. too many other distractions.
[14:45] <rtg> I can get to it today
[15:28] <kamal> Adri2000, apw, jsalisbury, henrix: fyi, that "revert" commit did not actually revert the brightness fix for bug #1163720 ...  the original fix commit applied the quirk to both the original XPS13 and the newer XPS13-FHD, but ...
[15:28] <ubot2> Launchpad bug 1163720 in linux (Ubuntu Raring) "Brightness control broken on XPS13 with 3.8.0-16" [Medium,Confirmed] https://launchpad.net/bugs/1163720
[15:29] <kamal> we then determined that it actaully broke brightness control on the XPS13-FHD (brightness control seemed to work on the -FHD without any additional fix needed), so ...
[15:29] <kamal> the commit "SAUCE: (no-up) drm/i915: revert PCH_PWM_ENABLE quirk for XPS13-FHD" actually just removed the application of the quirk for the XPS13-FHD.
[15:30] <kamal> at that point (3.8.0-21), all of the XPS13{,-FHD} users seemed satisfied.   so . . . .
[15:30] <henrix> kamal: ok, so do you think its worth building a test kernel reverting that revert?
[15:30] <kamal> if its broken again in 3.8.0-22 (arrrghghgh!) then we'll need an all new bug report -- not a reopen of 1163720
[15:31] <kamal> ... and the information:  is this on an XPS13, or an XPS13-FHD ?
[15:32] <kamal> henrix, first thing:   I'll test 3.8.0-22 on my (non-FHD) original model XPS13 as a sanity check
[15:33] <henrix> kamal: ok, cool. just a detail: i moved back the bug to 'confirmed'. you already said that's probably not the right thing to do, so...
[15:33] <kamal> henrix, I'll fix it
[15:33] <kamal> :-)
[15:34] <henrix> kamal: ok, cool. but maybe we want a new bug # first to add the comment before changing?
[15:34] <kamal> henrix, let me test -22 (will do momentarily) then we'll sort it out
[15:34] <henrix> ack
[15:37] <kamal> henrix, Adri2000: on my (non-FHD) original model XPS13, the brightness control still works fine for me with 3.8.0-22.33, so ...
[15:39] <kamal> Adri2000, is yours the new XPS13-FHD model, perchance?   I'm now not sure if the issue here is that the quirk *does* need to applied to some -FHD's but not others, or if something else in the i915 driver changed out from under me again . . .
[15:43] <rtg> ogasawara, remind me again, when does Raring LTS kernel go EOL ? when 14.04 LTS is published ? (which is longer then the 9 month support window for raring). I get so confused.
[15:52] <kamal> Adri2000, fyi, bug #1169376 is the one where we determined that applying the quirk broke the XPS13-FHD, hence the "revert" commit to remove the -FHD from the quirk list.
[15:52] <ubot2> Launchpad bug 1169376 in linux (Ubuntu) "XPS13 backlight stopped working after update 3.8.0-18.28" [Undecided,Confirmed] https://launchpad.net/bugs/1169376
[15:56] <ogasawara> rtg: 14.04.1 time frame
[15:56] <ogasawara> rtg: we wanted some baking time of the official 14.04 HWE kernel in Precise before we EOL'd the previous stacks
[15:57] <ogasawara> rtg: and indeed it'll be longer than the natural Raring support window of 9mo
[15:57] <rtg> ogasawara, we have a wiki page on this right ? I should start embedding that URL into the descriptions of the meta packages.
[15:57] <ogasawara> rtg: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
[15:58] <bjf[afk]> rtg, ogasawara if 14.04 follows a similar schedule to 12.04 then 14.04.1 would come out around the 3rd week in Aug. of 2014
[15:58] <rtg> which gives raring 14 months of support
[15:59] <bjf> rtg, the raring kernel anyways, yes
[15:59] <rtg> right
[16:34] <Kalidarn> i can confirm 3.8.0-22 panics 100% of the time 3.8.0-21 works fine though
[16:35] <bjf> Kalidarn, do you have a bug # ?
[16:35] <Kalidarn> pretty sure it is bug 1182038
[16:35] <ubot2> Launchpad bug 1182038 in linux (Ubuntu) "kernel panic fatal exception in interrupt" [High,Confirmed] https://launchpad.net/bugs/1182038
[16:36] <Kalidarn> i see that: VFS: Cannot open root device "UUID=<uuid>" or unknown-block(0.0: error -6
[16:36] <Kalidarn> it must be a nasty regression because i booted -22 3 times failed on all 3 times, then i booted -21 and it worked.
[16:37] <bjf> Kalidarn, can you start tracking that bug and contribute to the testing?
[16:37] <Kalidarn> sure
[16:38] <Kalidarn> hmm not sure if it is the same thing
[16:38] <Kalidarn> it seems to load module verification cerificates right.
[16:38] <bjf> Kalidarn, go ahead and open a new bug and we can worry about it being a dupe later
[16:39] <Kalidarn> "please append a correct "root=" boot option; here to the available partitions:
[16:39] <Kalidarn> i haven't edited my grub configs.
[16:51] <bjf> Kalidarn, did you open a new bug?
[16:52] <Kalidarn> bjf: bug 1183912 i filed is probably a duplicate but i don't really knwo
[16:52] <ubot2> Launchpad bug 1183912 in linux (Ubuntu) "Kernel 3.8.0-22 fails to boot." [Undecided,New] https://launchpad.net/bugs/1183912
[16:52] <Kalidarn> *know much more
[16:54] <Kalidarn> if anyone has any specific things they want me to test just ping my name, i really must be going to bed :)
[16:54] <Kalidarn> no doubt im not the only one effected
[16:54] <Kalidarn> though i suppose it could be a specific hardware configuration
[17:26] <bjf> Kalidarn, i'll add a test request to the bug
[17:30]  * rtg -> lunch
[17:54] <bjf> bjf -> lunch
[18:59]  * rtg -> EOW
[19:23] <bjf> i'm back
[19:25] <infinity> plars: Did we come to any conclusions about ti-omap4?
[19:27] <plars> infinity: sbeattie was looking at it, said he has a patch for the test
[19:27] <plars> infinity: but it did *not* fail on the older kernel
[19:28] <plars> ...
 sbeattie: and I did see it on two separate runs with the sru kernel
 sbeattie: now, 3 runs not sufficient to say it's not still a random occurrence, but I found it a bit odd
 works fine on 3.2.0-1430-omap4 #39 the problem happened on 3.2.0-1432-omap4 #41
[19:28] <plars> infinity: ^
[19:30] <infinity> plars: Could still be a fluke.  Or could be that the new kernel changed something entirely unrelated just enough to tickle a weird race in the test?
[21:42] <Adri2000> kamal: I don't know how can I reliably check what version of the XPS 13 I have (is it somewhere in the output of lshw or dmidecode?); but I know it has a full hd screen (aka I'm using 1920x1080 resolution)
[21:48] <plars> infinity: I think both sbeattie and I are at a loss, I've not been able to reproduce this timout when running the test in isolation
[21:49] <plars> infinity: but unless sbeattie disagrees, I think the risk is low because a) we know the test *can* pass because it works when I run it standalone, and b) it's not an explicit failure, just a timeout
[21:51] <infinity> plars: Yeah, I'm not fussed about it, especially if it's not breaking in isolation.  It may well just be a fluke that you tripped it twice.
[21:51] <plars> yes, known possibility
[21:51] <plars> I'll comment on the bug, but call it passed
[21:51] <infinity> plars: Odds are that you could trip it in isolation if you ran it a few thousand times (for i in `seq 1 3000`; do test.py; done), but meh.
[21:52] <plars> infinity: I suspect it may have something to do with previous tests getting the system slowed just enough
[21:52] <infinity> Could be coming out of swap death from the previous test(s), yes.
[21:52] <infinity> Restoring your entire system's RAM over a USB link isn't quick.
[21:53] <plars> indeed
[23:11] <sbeattie> plars, infinity: no objection from me.
[23:19] <infinity> sbeattie: Good deal, cause I already released it based on jjohansen's say-so. ;)
[23:20] <sbeattie> hehe
[23:20] <sbeattie> phew, I was worried for 30 seconds that my opinion might actually be important.
[23:21] <infinity> And the ABI checker is too quick.  It caught the LP OOPS that made the kernel/meta updates span a publisher cycle. :/
[23:22] <infinity> Oh well, should be all fixed now.