[01:17] <niemeyer> fwereade_: Yeah, sorry, I wasn't actually suggesting that
[01:17] <niemeyer> fwereade_: Just to put it in its own line, out of the block
[01:18] <fwereade_> niemeyer, cool, that was what I took it to mean, but best to check ;)
[01:21] <niemeyer> fwereade_: Thanks for checking out :)
[01:47] <bigjools> niemeyer or fwereade_, what starts up zookeeper?
[01:48] <bigjools> I am still not sure
[01:48] <niemeyer> bigjools: I believe it starts itself.. cloud-init installs it
[01:48] <niemeyer> bigjools: I might be wrong, though.. the cloud-init setup will tell for sure
[01:48] <bigjools> thanks, I was afraid of that
[01:48] <bigjools> it's not installed on my testing odev thing :(
[01:52] <bigjools> niemeyer: is it triggered via the kickstart file used in the cobbler's juju profile?
[01:53] <niemeyer> bigjools: It's triggered via cloud-init
[01:53] <bigjools> niemeyer: there's cloud-init stuff at the bottom of the kickstart
[01:54] <bigjools> and there's a different profile for non-juju nodes
[01:54] <bigjools> just trying to piece this together, it's hard
[02:04] <niemeyer> bigjools: Yeah, I can imagine, sorry about that
[02:05] <niemeyer> bigjools: The whole cobbler thing, though, was intended to simply run cloud-init, in a way attempting to make it a bit saner
[02:05] <bigjools> niemeyer: do you know if it relies on preseed data from juju to install it?
[02:05] <niemeyer> bigjools: So most of the magic there is intended to get closer to what EC2 would do
[02:06] <niemeyer> bigjools: It relies on the cloud-init user-data which we indeed deliver via kickstart
[02:06] <bigjools> ok
[02:14] <bigjools> niemeyer: does it do that when bootstrapping?
[02:15] <niemeyer> bigjools: Does it do what, more precisely?
[02:15] <bigjools> niemeyer: supply the zoopkeeper info to cloud-init for bootstrap
[02:15] <bigjools> or is it done later?
[02:15] <niemeyer> bigjools: All of the process is a side-effect of "juju bootstrap"
[02:15] <bigjools> ok thanks
[02:37] <niemeyer> bigjools: np
[02:38] <bigjools> niemeyer: ok I think I have it now - smoser changed cloud-init to pull all this from the metadata service instead of passing loads of stuff in the preseed.
[02:38] <bigjools> thanks again
[02:39] <niemeyer> bigjools: RIght, so that we can stay closer to EC2 and remain working as the logic advances
[12:43] <TheMue> morning
[13:01] <wrtp> TheMue: hiya
[13:42] <niemeyer> Good morning jujuers!
[13:43] <wrtp> niemeyer: hiya
[13:43] <niemeyer> wrtp:  Ho
[13:43] <wrtp> niemeyer: i updated lbox, but it didn't seem to make a difference to my checksum error.
[13:43] <fwereade_> heya niemeyer
[13:46] <niemeyer> wrtp: Hmm :(
[13:46] <niemeyer> fwereade_: Heya!
[13:46] <niemeyer> wrtp: What's the output again?
[13:47] <wrtp> hmm, it's just gone and worked!
[13:47] <niemeyer> wrtp: Hah.. love when that happens :)
[13:48] <wrtp> niemeyer: this was the output earlier this morning: error: Failed to send patch set to codereview: can't upload base of environs/ec2/internal_test.go: ERROR: Checksum mismatch.
[13:48] <fwereade_> niemeyer, heh, if anything that sort of thing utterly creeps me out ;)
[13:48] <wrtp> niemeyer: oh
[13:49] <wrtp> niemeyer: i thought it had worked, but it's still borked
[13:49] <wrtp> https://codereview.appspot.com/5796078/diff/1/environs/ec2/ec2.go
[13:50] <niemeyer> wrtp: I suggest deleting the CL, removing the reference to it from the description in the merge proposal, and running lbox again
[13:50] <wrtp> niemeyer: i did that last night, but i'll try again
[13:50] <niemeyer> wrtp: The new lbox might help
[13:50] <wrtp> niemeyer: i think it's possible it has something to do with a contents conflict in the history
[13:50] <wrtp> niemeyer: will try again
[13:52] <wrtp> niemeyer: same error
[13:52] <wrtp> niemeyer: error: Failed to send patch set to codereview: can't upload base of environs/ec2/internal_test.go: ERROR: Checksum mismatch.
[13:53] <niemeyer> wrtp: What's the new CL?
[13:53] <wrtp> niemeyer: it didn't tell me. but... i'll have a look in codereview
[13:53] <niemeyer> wrtp: Can you please paste the error then?
[13:54] <wrtp> niemeyer: http://codereview.appspot.com/5798076/
[13:54] <wrtp> niemeyer: error: Failed to send patch set to codereview: can't upload base of environs/ec2/internal_test.go: ERROR: Checksum mismatch.
[13:55] <niemeyer> wrtp: This CL was not created by the new lbox
[13:55] <wrtp> niemeyer: the branch is at lp:~rogpeppe/juju/go-zk-connect if you want to clone it and try for yourself
[13:56] <niemeyer> wrtp: Can you please update and try again?
[13:56] <wrtp> niemeyer: i did apt-get update, and apt-get install says i've got the newest version
[13:56] <wrtp> niemeyer: ok
[13:56] <niemeyer> wrtp: Well, your new version is not the new version that fwereade_ installed last night somehow
[13:56] <wrtp> niemeyer: running apt-get update again
[13:57] <wrtp> (what *is* it doing when it says "Waiting for headers"?)
[13:59] <wrtp> still updating...
[13:59] <wrtp> niemeyer: it says lbox is already the newest version
[14:00] <niemeyer> wrtp: What's the version you've got?
[14:00] <wrtp> niemeyer: how do i tell that?
[14:00] <niemeyer> wrtp: dpkg -l lbox
[14:00] <wrtp> niemeyer: 1.0-<IP_ADDRESS>
[14:01] <niemeyer> 37.1 or 37.10?
[14:01] <wrtp> 37.1
[14:02] <wrtp> niemeyer: i could try go getting it.
[14:02] <niemeyer> wrtp: What does "which lpad" tell you?
[14:02] <niemeyer> Erm
[14:02] <niemeyer> wrtp: What does "which lbox" tell you?
[14:02] <wrtp> niemeyer: bingo!
[14:02] <niemeyer> wrtp: Are you using a locally installed one?
[14:02] <wrtp> niemeyer: i'd done go get lbox before i guesws
[14:03] <niemeyer> wrtp: Aha, cool
[14:04] <niemeyer> wrtp: Not sure if this will really resolved the issue, though.. but let's see
[14:06] <wrtp> niemeyer: sorry, same error
[14:06] <niemeyer> wrtp: Can you please paste the command output again?
[14:07] <wrtp> niemeyer: do you want the verbose version?
[14:07] <niemeyer> wrtp: Yeah, that'd be helpful
[14:07] <niemeyer> wrtp: Please let me know of the final CL as well
[14:07] <wrtp> niemeyer: here's the CL it created BTW
[14:07] <wrtp> http://codereview.appspot.com/5795079/
[14:07] <wrtp> although i'm just about to delete that again, so hold on
[14:09] <wrtp> niemeyer: http://paste.ubuntu.com/881866/
[14:10] <wrtp> niemeyer: and the CL is this: http://codereview.appspot.com/5797083/
[14:11] <niemeyer> wrtp: Thanks
[14:11] <niemeyer> wrtp: When you mentioned there was a conflict in the history, what was that about?
[14:12] <wrtp> niemeyer: the file i referred to has been deleted and recreated in the branch history
[14:12] <wrtp> niemeyer: the branch i'm trying to push is not a direct descendant of the branches i've previously pushed, although it's been merged with them.
[14:13] <niemeyer> wrtp: Ouch
[14:14] <niemeyer> wrtp: Did the file exist at tip?
[14:14] <niemeyer> s/Did/does/
[14:14] <wrtp> niemeyer: yes, i think so
[14:14] <niemeyer> wrtp: So why was it removed and added?
[14:15] <wrtp> niemeyer: at some points in the history, there was no need for any internal tests, hence internal_test.go was removed.
[14:15] <niemeyer> wrtp: I see
[14:15] <niemeyer> wrtp: Hmm
[14:17] <wrtp> niemeyer: if i do a bzr diff, it should internal_test.go being removed and then created again with exactly the same content.
[14:17] <wrtp> s/should/shows/
[14:18] <niemeyer> wrtp: Yeah, that means the file was removed and re-added.. it's unfortunate that it loses the whole history when doing that
[14:19] <wrtp> niemeyer: yeah, it is
[14:20] <wrtp> niemeyer: and history is the reason i'm wanting to submit the branch as is - i have a sentimental attachment to some of the historical pieces...
[14:20] <niemeyer> I'm now just wondering if Rietveld itself is breaking down when it notices that the file has the same checksum before and after
[14:21] <niemeyer> Ah, maybe not..
[14:28] <niemeyer> wrtp: The file was removed and added in the same commit
[14:28] <wrtp> niemeyer: how is that possible?
[14:29] <wrtp> niemeyer: i guess i must have done bzr rm and then changed my mind
[14:29] <niemeyer> wrtp: I don't know, but that's what history shows
[14:29] <niemeyer> removed:
[14:29] <niemeyer>   environs/ec2/internal_test.go  internal_test.go-20120215173103-mc3cbfukg0redhy0-1
[14:29] <niemeyer> added:
[14:29] <niemeyer>   environs/ec2/internal_test.go  internal_test.go-20120222161404-ukvwz2ypn0g6plcc-1
[14:30] <wrtp> niemeyer: interesting question: what's the best way to undo a bzr rm ?
[14:30] <niemeyer> wrtp: That's exactly what I'm looking for right now
[14:30] <wrtp> niemeyer: most edits between commits are ephemeral...
[14:31] <niemeyer> wrtp: This seems to work: % bzr revert -r 101 ./internal_test.go
[14:31] <niemeyer> +N  environs/ec2/internal_test.go
[14:32] <niemeyer> wrtp: Please try to do this:
[14:32] <wrtp> niemeyer: i'm trying now
[14:32] <niemeyer> wrtp: cp internal_test.go{,.tmp}
[14:33] <niemeyer> wrtp: bzr revert -r 101 ./internal_test.go
[14:33] <niemeyer> wrtp: mv -f internal_test.go{.tmp,}
[14:33] <niemeyer> wrtp: bzr commit
[14:33] <niemeyer> Not sure if it'll work, actually
[14:34] <niemeyer> Nope
[14:37] <wrtp> no indeed
[14:43] <wrtp> lunch
[14:48] <niemeyer> wrtp: I believe I fixed it
[14:49] <niemeyer> wrtp: When you're back, please try to "bzr pull lp:~niemeyer/juju/go-zk-connect-fixup"
[14:49] <niemeyer> wrtp: Then, lbox propose
[14:50] <niemeyer> wrtp: If that works, I'll explain how I got it fixed, and how to avoid the problem in the future
[15:02] <wrtp> niemeyer: bzr: ERROR: These branches have diverged. Use the missing command to see how.
[15:02] <wrtp> oops
[15:02] <niemeyer> wrtp: I guess you have committed something else in your local branch?
[15:02] <wrtp> wrong directory!
[15:03] <wrtp> erm
[15:04] <wrtp> niemeyer: ah yes, i did a commit to try and solve the problem earlier
[15:04] <wrtp> (as suggested)
[15:04] <wrtp> i'll uncommit it
[15:05] <fwereade_> gents, I'm really tired; I'll be around again at some stage later today but right now I need a walk and a lie down
[15:05] <fwereade_> laters
[15:05] <wrtp> fwereade_: ok. enjoy the walk...
[15:06] <wrtp> niemeyer: ok, that worked, thanks!
[15:07] <wrtp> niemeyer: so... how did you fix it?
[15:07] <niemeyer> fwereade_: Have some good rest man
[15:08] <niemeyer> wrtp: In general, reviving a file is trivial: revert -r N file_name and bang.. we have the file back
[15:08] <niemeyer> wrtp: The problem in this case, is that the file has been revived with a different id
[15:08] <niemeyer> s/revived/added/
[15:08] <niemeyer> wrtp: So when we attempt to "bring it back", bzr actually picks the latest id used for that name
[15:09] <niemeyer> wrtp: The trick for getting the real original file back was to create another branch that still had the old file
[15:09] <niemeyer> wrtp: Then, remove the file locally, and add it back again with the new content, but using bzr add --file-ids-from $OLD_BRANCH
[15:09] <niemeyer> wrtp: This tricked bzr into looking at the original revision
[15:10] <wrtp> niemeyer: ah. i had no idea about --file-ids-from
[15:10] <wrtp> interesting
[15:12] <wrtp> niemeyer: BTW the CL now seems to have a file called "[revision details]"
[15:12] <niemeyer> wrtp: Yeah, that was intentional
[15:13] <niemeyer> wrtp: this used to be at the head of every diff, but unfortunately this makes Rietveld get lost in terms of diffing the diffs
[15:13] <niemeyer> wrtp: Now we'll be able to see which files actually changed between revision, as usual
[15:15] <wrtp> niemeyer: i'm not sure i understand - what exactly is that file showing?
[15:15] <niemeyer> wrtp: Have you clicked on it?
[15:15] <wrtp> niemeyer: yeah. i get two revision ids
[15:16] <niemeyer> wrtp: That's what this file is showing :-)
[15:16] <wrtp> niemeyer: what do the revision ids refer to? i'd've expected that one would refer to me, given i've created the latest revision in that branch.
[15:17] <niemeyer> wrtp: Sorry, I'm not sure I understand your question, since the revision ids are labeled
[15:17] <niemeyer> wrtp: They show the old revision id and the new revision id..
[15:17] <wrtp> niemeyer: ah! of course. you created the latest revision!
[15:17] <niemeyer> wrtp: :-)
[15:18] <niemeyer> wrtp: This information enable any patch set to be recovered exactly as proposed
[15:18] <niemeyer> enables
[15:19] <wrtp> niemeyer: hmm:
[15:19] <wrtp> % bzr diff --old<EMAIL_ADDRESS>[15:19] <wrtp> % bzr diff --old<EMAIL_ADDRESS>[15:19] <wrtp> %
[15:19] <wrtp> or maybe i can't use a revision id as a --old target
[15:20] <niemeyer>   --old=ARG             Branch/tree to compare from.
[15:20] <niemeyer> wrtp: you want -r
[15:20] <wrtp> i've not used revision ids in bzr before.
[15:20] <wrtp> i wonder why it didn't give an error
[15:21] <niemeyer> wrtp: Yeah, curious indeed
[15:22] <wrtp> niemeyer: ah, this worked:  bzr qdiff -r<EMAIL_ADDRESS>[15:22] <wrtp> i was missing the revid: prefix
[15:22] <wrtp> and the -r of course
[15:23] <niemeyer> wrtp: bzr diff -r<EMAIL_ADDRESS>[15:23] <niemeyer> wrtp: This works for me
[15:23] <wrtp> niemeyer: so it does.
[15:23] <wrtp> (for me too
[15:23] <wrtp> )
[15:24] <wrtp> niemeyer: thanks, that's useful.
[15:24] <niemeyer> wrtp: np
[15:24] <niemeyer> wrtp: I'll see if I take that lbox hackaton and implement the pre-req stuff later
[15:24] <niemeyer> after some further reviews
[15:25]  * wrtp is hoping to get this branch reviewed today :-)
[15:31] <wrtp> niemeyer: here's the cherry on the cake: https://codereview.appspot.com/5754103
[15:34] <wrtp> it feels very good to have that finally proposed!
[15:41] <niemeyer> wrtp: I've delivered a LGTM review
[15:41] <wrtp> niemeyer: yay!
[15:42] <niemeyer> wrtp: but I'm a bit unsure about what's going on there.. do we really have only a couple of changes to tests in that branch?
[15:42] <niemeyer> wrtp: Doesn't seem to match the description
[15:42] <wrtp> niemeyer: all it does is connect to the zookeeper that's already started as a result of the userdata changes in the previous branch.
[15:43] <niemeyer> wrtp: The description seems bogus then.. you're changing tests only
[15:43] <niemeyer> wrtp: It should say something like "Fix lack of tests!" :-)
[15:43] <TheMue> niemeyer: next step for the continued machine branch, will now use williams 'presence' for my 'agent' draft.
[15:43] <wrtp> hmm. you're right!
[15:44] <TheMue> niemeyer: oh, forgot the link, https://codereview.appspot.com/5690051/
[15:44] <niemeyer> wrtp: That TestBootstrap should be reverted too
[15:44] <wrtp> niemeyer: TestBootstrap can't work against the ec2test server
[15:44] <wrtp> hmm
[15:45]  * wrtp goes to look
[15:45] <wrtp> niemeyer: yeah, maybe we should have TestBootstrap and TestBootstrapAndOpen
[15:45] <wrtp> niemeyer: and avoid running the latter against ec2test
[15:46] <niemeyer> wrtp: It certainly feels pretty bad that we won't be testing all of that logic locally anymore
[15:46] <wrtp> niemeyer: that will make the live tests take a lot longer though
[15:47] <niemeyer> wrtp: Isn't that the whole purpose of having two different set of tests, one that opens and runs all tests, and one that does not
[15:47] <niemeyer> wrtp: I feel like we're getting lost in that mess of suites
[15:48] <wrtp> niemeyer: well, the point of the Live tests is that they're designed to be run against amazon. and as an added bonus we can run most of them locally as well.
[15:48] <niemeyer> wrtp: That's not what I'm talking about.. we have 4 suites, right?
[15:48] <niemeyer> wrtp: Why?
[15:49] <wrtp> two cross-provider suites; two ec2-specific suites.
[15:49] <wrtp> niemeyer: each for live vs local
[15:51] <wrtp> niemeyer: that Bootstrap logic is also tested inside the non-live test suite
[15:51] <wrtp> niemeyer: running the live suite locally is just a nice thing to do when we can. but in this case we can't.
[15:53] <niemeyer> wrtp: Running the live suite locally is the base strategy we've been using for testing juju's ec2 provider
[15:53] <niemeyer> wrtp: If we drop those tests, logic is effectively going untested
[15:55] <wrtp> niemeyer: yeah, we do rely on some of those tests, but we don't really want to duplicate the code.
[15:56] <wrtp> niemeyer: maybe it would be better the other way around - if LiveTests selectively imported from LocalTests.
[15:56] <niemeyer> wrtp: I'm starting to dislike that organization of tests altogether
[15:57] <niemeyer> wrtp: We're getting lost very easily
[15:57] <wrtp> niemeyer: yeah, it's not ideal. but i think the ideal of having some provider-independent tests is a good one.
[16:06] <niemeyer> wrtp: Yeah, maybe we should try to have the zk running in the local tests as well..
[16:06] <niemeyer> wrtp: But we'll face a road block very soon
[16:06] <niemeyer> wrtp: So I'm not really sure it's worth it
[16:07] <wrtp> niemeyer: yeah, i dunno.
[16:08] <niemeyer> wrtp: I think LiveTests should bootstrap just once
[16:08] <niemeyer> wrtp: Unless we're testing something that knowingly destroys the environment
[16:09] <niemeyer> wrtp: We have to avoid that fear that introducing new tests will slow things down
[16:09] <niemeyer> wrtp: Otherwise we'll stop writing tests..
[16:09] <niemeyer> wrtp: So the bootstrap itself would happen at SetUpSuite
[16:09] <wrtp> niemeyer: what about the tests that don't require a bootstrapped environment?
[16:10] <wrtp> niemeyer: maybe it should happen on demand, but once only.
[16:11] <niemeyer> wrtp: Right, that sound snice
[16:12] <wrtp> niemeyer: it's a pity in a way that gocheck runs tests in alphabetical order. it would be nice to arrange things so that the weaker tests run first.
[16:12] <niemeyer> wrtp: In fact, we already do that..
[16:12] <niemeyer> wrtp: That was the whole idea behind t.Open
[16:13] <niemeyer> Somehow we lost it
[16:13] <wrtp> niemeyer: Open is quite different from Bootstrap though
[16:13] <niemeyer> wrtp: Maybe..
[16:13] <wrtp> niemeyer: but i agree, that kind of thing should work
[16:13] <niemeyer> wrtp: I'll have to step out for lunch as Ale is waiting.. let's continue that conversation in 1h
[16:14] <wrtp> niemeyer: sounds good
[16:52] <robbiew> niemeyer: fyi...movement on the charm store RT...they are requesting a call with you
[17:07] <TheMue> fwereade_: arg, thx, when creating a function it indeed should be used. will fix it.
[17:07] <fwereade_> TheMue, cheers
[17:27] <niemeyer> robbiew: Aweosme!
[17:30] <niemeyer> wrtp: So, tests..
[17:30] <wrtp> niemeyer: yeah
[17:30] <wrtp> niemeyer: i've just added a bootstrap flag
[17:31] <niemeyer> wrtp: flag?
[17:31] <wrtp> niemeyer: so that live tests can call Bootstrap and it'll only bootstrap if another test hasn't already bootstrapped
[17:31] <wrtp> niemeyer: a state variable rather than a flag, really
[17:32] <niemeyer> wrtp: This is a test-specific detail..
[17:32] <niemeyer> wrtp: It's a problem for the suite to handle
[17:32] <wrtp> niemeyer: the variable is inside the suite
[17:32] <niemeyer> wrtp: So by "state" you mean "suite"?
[17:33] <wrtp> niemeyer: yeah. i meant state in the generic sense of a variable that records the state of something (in this case whether we've bootstrapped already)
[17:33] <niemeyer> wrtp: Ah, ok.. we have too many states :_)
[17:33] <wrtp> :-)
[17:34] <niemeyer> wrtp: I think the method in the suite should be something like BootstrapOnce, to differentiate from the Bootstrap method we already have in the Tests suite
[17:34] <wrtp> niemeyer: i'm also adding a flag inside jujutest.LiveTests which indicates whether it's possible to connect to the juju state.
[17:34] <niemeyer> wrtp: Ok
[17:35] <wrtp> BootstrapOnce sounds good. (although it might do it again if you deliberately call Destroy)
[17:36] <wrtp> niemeyer: BTW i'm interested to hear ideas as to how to better structure the test suite.
[17:37] <niemeyer> wrtp: Yeah, not sure yet.. the complexity is just a bit overwhelming at the moment
[17:37] <niemeyer> wrtp: 2 base suites, 4 suites in ec2, multiple scenarios, etc etc
[17:37] <wrtp> niemeyer: yeah. perhaps the multiple scenario stuff should go.
[17:38] <wrtp> niemeyer: (although it did catch some useful errors earlier on)
[17:39] <wrtp> niemeyer: the other stuff seems difficult to avoid though.
[17:40] <niemeyer> wrtp: I think we can just pick the harsher scenario and go with it
[17:41] <wrtp> niemeyer: not always easy to know which is "harsher". different scenarios can expose different bugs.
[17:42] <wrtp> niemeyer: but i think i'll just go with "extra-instances"
[17:43] <niemeyer> wrtp: I find it easy to see which one is likely to yield bugs
[17:43] <wrtp> niemeyer: i don't think we care too much if instances come up in initial running state.
[17:43] <niemeyer> wrtp: Pre-existing instances is trickier to handle than an empty environment
[17:43] <wrtp> niemeyer: yeah, that one's an easy call.
[17:44] <niemeyer> wrtp: Handling an instance in an intermediate state before running also is the less trivial path than getting instances running upfront
[17:44] <wrtp> niemeyer: another one though, that we might want to do in the future, is eventual consistency. but perhaps we just always test for maximum eventual consistency delay.
[17:44] <niemeyer> wrtp: Yeah.. I think we should have a reasonable delay that is likely to yield bugs but does not cause the suite to be extremely boring
[17:45] <niemeyer> wrtp: Then, we can have something like Go's -cpu setting for tests
[17:45] <niemeyer> wrtp: So that we can tweak that value for specific runs
[17:45] <wrtp> niemeyer: seems plausible
[17:46] <wrtp> niemeyer: (it'd be nice if gocheck could run tests concurrently BTW)
[17:46] <niemeyer> wrtp: Yeah, it will eventually
[17:51] <niemeyer> rebooting.. apparently Unity is now fixed and won't pop up the HUD all the time.. Woohay.
[18:03] <niemeyer> Heh.. the upgrade *removed* unity..
[18:03] <niemeyer> But the HUD issue is gone indeed
[18:03] <wrtp> niemeyer: this is why we need better error messages from state:
[18:03] <wrtp> /home/rog/src/go/src/launchpad.net/juju/go/environs/jujutest/livetests.go:72:
[18:03] <wrtp>     c.Assert(err, IsNil)
[18:03] <wrtp> ... value syscall.Errno = 0x2 ("no such file or directory")
[18:03] <wrtp> niemeyer: i've gotta go
[18:04] <wrtp> niemeyer: PTAL; i haven't had a double check of it, but it might be ok :-)
[18:04] <wrtp> https://codereview.appspot.com/5754103
[18:04] <niemeyer> wrtp: This is why we need better *error messages*
[18:04] <niemeyer> wrtp: Let's not take the leap from there onto saying we *have* to implement a given approach
[18:04] <niemeyer> wrtp: We already discussed improving error messages, and haven't done it yet
[18:05] <wrtp> niemeyer: sure. i'm not saying that my suggested approach is the only one that'll work.
[18:05] <wrtp> anyway, i'm  being shouted for!
[18:05] <niemeyer> wrtp: Have fun :)
[18:05] <wrtp> niemeyer: see you tomorrow
[18:07] <niemeyer> wrtp: These error messages look like an issue in your local setup, btw.. there are no elements of "launchpad.net/goamz/aws" in /home/rog/src/go/src
[18:08] <niemeyer> wrtp: Sorry, that was about a pretty old paste you made
[18:08] <niemeyer> wrtp: ECONTEXT
[18:30] <niemeyer> hazmat: ping
[18:30] <hazmat> niemeyer, pong
[18:30] <niemeyer> hazmat: Yo
[18:30] <niemeyer> hazmat: I'm reviewing the Go branch that implements RemoveMachine in state
[18:31]  * hazmat nods
[18:31] <niemeyer> hazmat: I recall we had some good exchanges around the idea that machines shouldn't simply disapear
[18:31] <niemeyer> disappear
[18:31] <niemeyer> hazmat: Have you ever touched that area in the Python incarnation?
[18:32] <hazmat> niemeyer, that api should still be present for the final removal, but the machine agent shouldn't be killed by just removing its state and killing the machine, instead it should have a state communication/coordination around its termination to shutdown graceful before being executed permantently
[18:32] <hazmat> ie. we don't kill identity of an actor before it has a chance to shutdown gracefully
[18:33] <hazmat> but after it does or a suitable timeout, we do go ahead and remove the state
[18:33] <hazmat> so the state api for removal should still be present
[18:34] <hazmat> but the api act of stopping a machine uses a state protocol before the provisioning agent uses removemachine
[18:34] <niemeyer> hazmat: Yeah, I recall that.. but have you ever implemented anything?
[18:35] <hazmat> niemeyer, no.. its the last bug marked critical for 12.04, i'm going to a spec to the list this after i return from pycon sprints tomorrow
[18:35] <hazmat> ^get
[18:35] <niemeyer> hazmat: Ah, cool
[18:35] <hazmat> niemeyer, i've got draft in lp:~hazmat/juju/unit-stop
[18:35] <niemeyer> hazmat: RemoveMachine will certainly change.. it has to be split in two
[18:36] <hazmat> niemeyer, i figure just a different api ... like stopmachine.. that will in turn remove machine when its done
[18:36] <niemeyer> hazmat: "stop machine" implies something else.. "stop" has the "start" counterpart
[18:36] <hazmat> true
[18:37] <niemeyer> hazmat: Well, I guess we could model it that way even..
[18:37] <niemeyer> hazmat: stop => remove.. or stop => start..
[18:42] <niemeyer> hazmat: How's subordinates going, btw?
[19:23] <niemeyer> TheMue: You've got another review
[19:28] <TheMue> niemeyer: thx, done a first scan. your comment critics is ok. i'm just used to take them sometimes for optical block building. but i can live w/o them here.
[19:29] <niemeyer> TheMue: Thanks!  I feel a bit on the other side.. if there's a comment, I'll always read it while skimming through the code.. the fact the comment says nothing is distracting
[19:30] <TheMue> niemeyer: i'll remove them and be more keen on better helping comments if i feel they are needed
[19:41] <niemeyer> TheMue: Thanks a lot
[19:41] <niemeyer> TheMue: On the bright side, there are only trivial details really.. the branch is very nice
[19:43] <TheMue> niemeyer: thx, williams argument regarding RemoveMachine() has been good
[20:01] <niemeyer> TheMue: Please don't forget to lbox propose again (just got the review DOnes)
[20:02] <TheMue> niemeyer: done the propose
[20:07] <niemeyer> TheMue: LGTM!
[20:07] <niemeyer> WOohay, one more branch..
[20:09] <TheMue> niemeyer: great, thx, will submit it
[20:17] <niemeyer> TheMue: Have you done any changes in https://codereview.appspot.com/5782053/ that are ready for review?
[20:17] <niemeyer> TheMue: I'm asking only because you mentioned something earlier on
[20:18] <niemeyer> TheMue: I know it's late for you, so just wondering if you have something that is already ready
[20:20] <TheMue> niemeyer: the proposal works, but currently w/o the presence solution of william. i'll integrate it tomorrow.
[20:20] <niemeyer> TheMue: Ok, super
[20:21] <TheMue> niemeyer: but for today i say good night ;)
[20:22] <niemeyer> TheMue: have a good night!
[20:23] <TheMue> niemeyer: thx, cu tomorrow
[21:15] <andrewsmedina> niemeyer: hi
[21:32] <niemeyer> andrewsmedina: Hey
[21:33] <andrewsmedina> niemeyer: tonight I will send another code for review related with lxc
[21:33] <andrewsmedina> niemeyer: and I have a doubt
[21:34] <niemeyer> andrewsmedina: Sure, what's up?
[21:35] <andrewsmedina> niemeyer: I need create another branch for work with the local environment or I can use the same branch that I'm using for lxc?
[21:35] <niemeyer> andrewsmedina: One branch, one proposal, one submit
[21:36] <andrewsmedina> niemeyer: Will be a proposal for lxc and another for local environment?
[21:37] <niemeyer> andrewsmedina: The smaller and more self contained a proposal/branch is, the best for us to review, and the best for you to fix it for inclusion
[21:37] <niemeyer> andrewsmedina: Your initial lxc/local branch is great
[21:37] <niemeyer> andrewsmedina: But it's pending some fixes
[21:37] <andrewsmedina> niemeyer: I know
[21:38] <niemeyer> andrewsmedina: It has to be fixed accordingly, and updated ("lbox propose" again)
[21:38] <andrewsmedina> niemeyer: II already have fixed that issues, and I add another methods to lxc container type
[21:40] <niemeyer> andrewsmedina: Other methods should be in a different proposal
[21:40] <niemeyer> andrewsmedina: Once a proposal is made, the issues pointed out should be fixed, so that we can include it
[21:40] <andrewsmedina> niemeyer: hm..
[21:40] <niemeyer> andrewsmedina: Otherwise we get into a never-ending cycle
[21:41] <andrewsmedina> niemeyer: you're right
[21:42] <andrewsmedina> niemeyer: thanks
[21:42] <niemeyer> andrewsmedina: Thank you
[22:19] <niemeyer> Heading out for dinner with some friends.. back later


[13:17] <alkisg> KitsuWhooa: hi, so, any idea where should we report this? To nouveau upstream? To xorg? To ubuntu?
[13:17] <KitsuWhooa> I'm still working on it
[13:18] <alkisg> Ah great
[13:18] <KitsuWhooa> bisecting goes from one bug to another
[13:18] <alkisg> Btw I haven't heard of any instability issues with pageflip off, from a lot of schools
[13:18] <alkisg> Haha
[13:18] <KitsuWhooa> https://tasossah.com/s/126f55d9cdb3.jpg
[13:19] <alkisg> Are you trying on tnt2 with the segfault, or on the other ones with the corruption?
[13:19] <KitsuWhooa> tnt2
[13:19] <KitsuWhooa> Looking at the code through gdb, the issue is probably somewhere in DIX. It's a bit of a maze
[13:20] <alkisg> Hmm, well, even if you fix the real issue that is the segfault, you wouldn't fix the issue that exposed the segfault, i.e. the lack of initialization somewhere, right?
[13:20] <KitsuWhooa> That is exactly what I am trying not to do
[13:20] <KitsuWhooa> if I wanted to do that, I could add a check for a valid pointer, and if not return
[13:21] <KitsuWhooa> but I doubt that would work
[13:23] <KitsuWhooa> nouveau calls this https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa.c#n66 and this returns an invalid pointer
[13:24] <KitsuWhooa> and ExaPixmapPriv is a macro
[13:24] <KitsuWhooa> which is here
[13:24] <KitsuWhooa> https://cgit.freedesktop.org/xorg/xserver/tree/exa/exa_priv.h#n283
[13:25] <KitsuWhooa> and this in turn calls DIX functions/macros
[13:56] <alkisg> KitsuWhooa: would it be possible to do this? (1) dump vars (2) run xrandr 640x480; xrandr 1366x768; (3) dump vars
[13:56] <alkisg> (1) would be different from (3) in the vars that are not initialized
[13:56] <KitsuWhooa> not really
[13:56] <KitsuWhooa> the function gets called multiple times
[13:57] <alkisg> I'm not talking about the function
[13:57] <alkisg> Suppose xorg somewhere has a variabled named, I dont know, other_page_resolution
[13:57] <alkisg> And this in turn messes things up, and breaks where you see it, but you can't trace it back to the wrong initialization,
[13:58] <alkisg> so, since xrandr does initialize that internal xorg variable, wouldn't comparing before/after help locate the uninitialized var?
[13:58] <KitsuWhooa> If it's an uninitialized variable, I can probably use valgrind to detect it
[13:58] <KitsuWhooa> dumping every single variable would be very impractical, if not impossible
[13:58] <alkisg> Well since 2 xrandr calls fix it, wouldn't that be the case?
[13:59] <alkisg> I haven't programmed in C/assembly in recent days, but in the old days, I could dump the whole data/stack etc segments and compare
[14:00] <alkisg> And then check the address in the linker to find the variable there...
[14:00]  * alkisg googles about valgrind...
[14:00] <KitsuWhooa> if you go low level like that, possibly
[14:01] <KitsuWhooa> but due to the "refresh rate", you'd probably get a lot of false positives
[14:03] <alkisg> Wow, just as easy as "valigrind myprogram"? !
[14:04] <KitsuWhooa> yup
[14:04] <alkisg> That sounds too good!
[14:04] <KitsuWhooa> I just switched to one of the cards that have just corruption
[14:04] <KitsuWhooa> so let's see what valgrind says
[14:04] <alkisg> Great
[14:04] <KitsuWhooa> alkisg: does epoptes-client restart whenever a user logs in?
[14:05] <alkisg> There are 2 epoptes-client processes. The system one and the session one. The session one starts on login, so yeah.
[14:05] <KitsuWhooa> Because I found that if I kill the one running already and run it manually from a tty, it doesn't kill the remote sessions
[14:05] <alkisg> You can't kill epoptes (to avoid students doing so),
[14:05] <KitsuWhooa> from a root vt?
[14:05] <alkisg> pkill -QUIT -U "$UID" -f '^epoptes-client$'
[14:05] <alkisg> This sends it a QUIT signal, which it respects
[14:05] <alkisg> Otherwise it restarts
[14:05] <KitsuWhooa> I kill -9 its PID
[14:05] <KitsuWhooa> oops
[14:06] <KitsuWhooa> it doesn't restart for me
[14:06] <alkisg> There's a timeout in the restarting
[14:06] <KitsuWhooa> Ah, I see
[14:06] <alkisg> So you may start it 20 seconds later, and it might be restarted 60 seconds later, killing your "20 seconds later" instance
[14:07]  * alkisg wants to simplify this now with systemd which supports restarting
[14:07] <KitsuWhooa> it doesn't seem to kill it
[14:07] <KitsuWhooa> all I know is that I do that and I can use the shell across X restarts/crashes
[14:08] <alkisg> Make sure UID is defined
[14:08] <alkisg> Eh, you should be able to use the root epoptes-client without restarting it
[14:08] <alkisg> It survives xorg crashes
[14:08] <KitsuWhooa> Once I am done with this I can probably tell you how to reproduce it
[14:09] <KitsuWhooa> and I checked stdout/err and it says nothing when it dies
[14:09] <KitsuWhooa> something complains about socat dying
[14:09] <KitsuWhooa> but I don't think that's the cause
[14:10] <alkisg> Btw if it helps, you can also enable sshd on ltsp clients
[14:10] <alkisg> I never had that issue though, with root epoptes-client dying
[14:10] <KitsuWhooa> it would help, but this ugly workaround seems to be okay so far
[14:10] <KitsuWhooa> so no need yet
[14:12] <KitsuWhooa> would also be nice if there was an easy file transfer option
[14:12] <KitsuWhooa> I just pipe tar to netcat at the moment
[14:12] <KitsuWhooa> to send compiled binaries to clients
[14:14] <KitsuWhooa> that is a lot of uninitalised byte warnings
[14:19] <alkisg> I use python -m SimpleHTTPServer on the server, and wget server:8000/file on the clients, or scp
[14:20] <alkisg> or sshfs
[14:20] <alkisg> There's also LOCAL_APPS_EXTRAMOUNTS=/some/folder in lts.conf, which sshfs's it for you on login
[14:21] <alkisg> Or you can login and /home/username is automounted, and put binaries there on the server, and run them on the client
[14:21] <alkisg> ...the downside being that you need X to login :D
[14:21] <KitsuWhooa> yeeeeah
[14:21] <KitsuWhooa> was about to say that there is nothing in /home/
[14:27] <KitsuWhooa> I don't see anything immediately related in the valgrind output


[00:05] <chuckmcm> Any system where the root boot device is immutable during normal system operation.  I know of at least one signage company where the "signage" OS (linux based) is booted from USB, and the "default" system has a copy of windows on it
[00:06] <chuckmcm> the manufacturer for the hardware does all their tests on Windows. But the dedicated signage app is a Linux application.
[00:07] <chuckmcm> They create a distro with their app on it on a bootable USB, plug it into the hardware on site and "poof" the sign lights up with their material
[00:07] <chuckmcm> the actual hardware is just a PC where the boot order is set to boot USB before the internal hard drive
[00:11] <craigbass76> I'm trying to shrink an ntfs partition from a livecd. Gparted can't do it wihtout ntfs-3g (which I got installed) and ntfsprogs, which when I try apt-get insalling it tells me there's no installation candidate. What's missing? I've only got one 16.04 box in the house and I've not used it much yet
[00:20] <soiled> root boot device.. not the root directory of the OS itself?
[00:21] <soiled> if i understand correctly you need sudo to install updates to the OS
[00:21] <soiled> security patches, etc
[00:23] <soiled> craigbass76, i think there's an apt-get feature that lets you search for similar filenames, in case 'ntfsprogs' is a typo of some sort
[00:23] <chuckmcm> soiled: depending on what your end goal is, you can remount root rw, update, then remount ro.
[00:23] <chuckmcm> (craigbass76 apt-cache search ntfs)
[00:24] <soiled> ah alright chuckmcm, thanks. i'll check that out.
[00:24] <chuckmcm> however  soiled since automatic updates assume a writable root file system and your going to have to change systems tools to work with a read only root file system you won't be able to use existing tools.
[00:25] <soiled> ah i couldn't change root from rw to ro if i'm using the flashdrive
[00:26] <chuckmcm> Well not and expect all "straight from the distro" tools to work. Sometimes things write back to their /etc directories, or /run etc. You'll no doubt have /run symlinked out to a RAM partition etc.
[00:27] <chuckmcm> This is well plowed territory in the embedded linux space so I really think you will want to start there.
[00:27] <soiled> ok, i will. thank you.
[00:39] <craigbass76> chuckmcm, hrmmm ntfs-config looked likely, but I'm getting the same message
[00:41] <craigbass76> Thes earen't kernel modules that require a reboot are they?
[00:41] <craigbass76> And I just did this lasst night on another Windows 7 box with the same cd. Weird.
[00:42] <chuckmcm> there may be. As I recall I needed to reboot after installing cifs-utils
[00:46] <craigbass76> Ahh. That won't work so well I guess on a livecd
[00:47] <craigbass76> I wish this person would just let me install Xubuntu...
[00:50] <chuckmcm> or physically remove the drive and connect it to a system running Xubuntu :-)
[00:51] <chuckmcm> I've got one of those USB to SATA/PATA/IDE drive adapters for just such cases.
[01:36] <ax562> anyone recommend a good virtual machine setup tutorial for xubuntu?
[01:53] <pleia2> ax562: have you tried virtualbox?
[01:53] <pleia2> it's slower without virt in the CPU, but it works
[01:54] <ax562> not running windows atm
[01:54] <ax562> that's only windows right?
[01:54] <pleia2> no...
[01:54] <pleia2> I use it on xubuntu all the time, I use the linux version
[01:55] <pleia2> apt-get install virtualbox
[01:55] <ax562> ah is that through ubuntu software center
[01:55] <Unit193> pleia2: You don't use the Windows one inside a Windows kvm?
[01:55] <ax562> no vt-x needed
[01:55] <ax562> ?
[01:55] <pleia2> Unit193: I don't use windows anywhere in any form!
[01:55] <ax562> hahah
[01:56] <pleia2> ax562: if you have vt-x it will use it, but it's not required
[01:56] <ax562> thanks :)
[01:56] <pleia2> you're welcome
[01:57] <ax562> woot
[01:57] <ax562> tiny app
[02:38] <ax562> do you guys usually install xubuntu on vm or just try it from iso?
[02:40] <eggggs>  for me installs go so fast on xubuntu  that i try to install it all and if i crash it reformat
[02:44] <ax562> thanks eggggs
[02:44] <ax562> going really slow btw :/
[02:47] <eggggs> whats going slow ax562
[02:47] <ax562> my vm install of xubuntu 16.10
[02:48] <eggggs> i think alot of that depends on power of pc and settings of vm , so many variables
[02:48] <ax562> yeah i chose dynamic hdd and also I have crap cpu :/
[02:49] <eggggs> live cds are slow to load but use all ram and full power of pc
[02:50] <eggggs> im still learning  vm stuff and usually crash the vm ehhe
[02:51] <ax562> haha
[02:51] <ax562> i've run vm before but not often
[02:51] <ax562> i usually just partition hd and install
[06:15] <nomad> Hi, does anyone know how to disable or edit the right click context menu in xfce4?
[06:33] <nomad> Anyone?
[06:34] <flocculant> https://forum.xfce.org/viewtopic.php?id=6981 post 10 - not sure if that'll still work with xfce4.12 though
[06:36] <pavlushka> nomad: you are new here?
[06:38] <nomad> yes
[06:38] <nomad> Not the right place?
[06:38] <flocculant> nomad: yes it's the right place :)
[06:39] <nomad> Disabling the desktop entirely is not an option i need the icons.
[06:40] <flocculant> nomad: to be honest I'm not sure there is a simple way to do what you want
[06:40] <nomad> If it's not possible to disable the context menu I could live with editing out a few things but i haven't found anything useful on the net.
[06:40] <nomad> I wasn't going for easy, flocculant.
[06:41] <flocculant> nomad: then you probably need to look into compiling it with things disabled
[06:42] <flocculant> you might be better using the xfce forum https://forum.xfce.org/
[06:42] <flocculant> I assume that was you asking the same on askubuntu yesterday?
[06:42] <nomad> yes.
[06:43] <nomad> Do you know which application provides the context menu?
[06:44] <flocculant> nope
[06:44] <nomad> ok, then I'll ask the forum, maybe someone knows.
[06:45] <nomad> or would the mailing list be a better palce?
[06:45] <flocculant> maybe
[06:45] <flocculant> both :)
[07:21] <nomad> flocculant: thank you for your help.
[07:24] <flocculant> nomad: welcome - even if I couldn't much :)
[07:25] <ax562> flocculant I\m back.  couldnt sleep
[07:53] <ax562> flocculant running deluge but not working in 16.10
[08:14] <Unit193> ax562: Bug 1593428
[08:15] <ax562> Unit193 how can I reference that without "bugging" anyone here?
[08:32] <Unit193> Eh?
[08:32] <Unit193> There's a "Affects me too" button at the top of the bug report.
[08:32] <ax562> I mean how can I check if bug has been reported?
[09:03] <ax562> https://bugs.launchpad.net/ubuntu/+source/libtorrent-rasterbar/+bug/1593428/+choose-affected-product
[15:30] <choki> does xubuntu still need more ram than vanilla xfce?
[21:57] <ax562> hello
[23:18] <ignatio> good evening all
[23:36] <ax562> hi
[23:51] <ax562> what\s the best way to check if bug has been reported?


[11:19] <keesj> Hi
[11:19] <Keybuk> hey
[11:22] <keesj> I am playing with upstart. I am trying to implement a state machine for my system
[11:23] <keesj> I wonder if it makes sence :). the big idea would be to emit events from userland or the kernel and handle upon them in upstart
[11:24] <keesj> I have a 3 gui apps that will run (not at the same time)
[11:27] <keesj> I would like to be able to emit "high" level events "start_mass-storage-app" and translate that into  a few command (insmods perhaps) and starting a gui
[11:27] <keesj> can I emit such event from within a job
[11:28] <keesj> simply saying.. can I emit events from withing a jobs
[11:36] <Keybuk> sure
[11:38] <keesj> by calling initctl ?
[11:40] <Keybuk> right
[11:41] <keesj> there is no "emit" command"
[11:46] <Keybuk> there is
[11:46] <Keybuk> initctl emit
[12:12] <keesj> thanks
[12:12] <keesj> I installed upstart in a different directory... I need to prefix the initctl command :(
[12:12] <Keybuk> you can make an "emit" command by just symlinking to initctl :p
[12:12] <Keybuk> right
[12:13] <Keybuk> fixing that is on the TODO
[12:13] <keesj> that's nice
[12:21] <keesj> and would there be a way to store the current states so I can ask it again later?
[12:22] <Keybuk> how do you mean?
[12:23] <keesj> just like runlevels work ( that you can ask the current runlevel)
[12:23] <Keybuk> still not 100% following
[12:23] <keesj> I would like to keep some variable to implement my state
[12:24] <keesj> if (in_mass_storage) and usb unplugged -> rmmod ...
[12:24] <keesj> in_mass_storage would be a state
[12:26] <keesj> in the sample scripts "they" do         set $(runlevel --set 1 || true)
[12:27] <keesj> to determine if an event gets handled based on the previous runlevel (this is sample code named rc1)
[12:28] <Keybuk> right, I'm kinda trying to get to that point
[12:28] <Keybuk> where upstart has states that are true or false
[12:28] <keesj> you are one of the developers, cool
[12:29] <Keybuk> heh, the upstart developer
[12:29] <keesj> yo!
[12:30] <keesj> I am currently testing by using a qemu (I first tried a chroot ) but the apparently was not the best way to do things
[12:30] <Keybuk> I just have it installed by default
[12:31] <Keybuk> it replaces sysvinit well enough
[12:31] <Keybuk> you can carry on running the old init scripts while playing/developing
[12:32] <keesj> I am playing with it for mamona so it is an embedded platform (under arm)
[12:33] <keesj> do you happen to know this package? http://smc.sourceforge.net/ (state machine compiler)
[12:39] <Keybuk> I don't, no
[12:41] <keesj> I used it a lot to create state machines. but basicaly you need "previous_state" + event to implement this
[12:42] <Keybuk> right
[12:42] <Keybuk> depends what you want to do, really
[12:43] <keesj> the "quick" hack would be to misues the initctl to tell init to change it's own "environement"
[12:44] <keesj> thanks for your time btw (I really apreaciate it)
[12:44] <Keybuk> right, but I'm not sure I fully understand what you want to achieve
[12:47] <keesj> hmm . perhaps I am just thinking the wrong way around. let me try to give a simple example
[12:51] <keesj> my system can have twoo states "video playback" and "mass storage".
[12:52] <keesj> if somebody presses the power button while in mass storage I don't like that so I would like to ignore a "power" event when in storage mode.
[12:53] <keesj> I was thinking in the line of creating a "button" event handler that listend to power_on power_off event
[12:54] <keesj> other events would be something like usb_connected (being a good reason to switch to mass storage)
[13:00] <keesj> I think I am taling about level events
[13:00] <Keybuk> what other kinds of decision would you make based on these states though/
[13:04] <keesj> whell I have a few of those event flying in (usb state changes, button presses, system update event) I was also thinking of using this state when going in "suspend" mode
[13:04] <keesj> so that when I wakeup I know what program to start again
[13:05] <Keybuk> when suspending why do you need to stop programs?
[13:06] <keesj> good questions :p
[13:09] <keesj> currenty I had to do it because I don't get events when in suspend , so if the device is in video mode , I suspend , and plug it to a computer , I miss the "connected" event
[13:09] <keesj> (just like udev meesd to cache the events generated by the kernel , I guess this is not the scop of upstart :p
[13:13] <keesj> I am getting there !
[13:14] <Keybuk> not entirely sure yet what the scope of upstart is ;)
[13:16] <keesj> haha
[13:17] <keesj> the code looks very clean
[14:12] <keesj> are you at fosdem?
[14:20] <Keybuk> no
[14:23] <Keybuk> I've never been to one of those
[14:37] <Keybuk> http://upstart.ubuntu.com/wiki/RemoveEventArguments
[14:37] <keesj> I can be nice :op
[14:37] <Keybuk> Any objection?  no?  good!  :o)
[14:39] <keesj> haha
[14:39] <keesj> it
[14:41] <keesj> I really just should al be programmed in lua
[14:42] <Keybuk> why?
[14:44] <keesj> I see plenty discussion about creating, "combined events" or other other structs that would be possible if upstart used a scripting language for the events definitions
[14:44] <keesj> but the current aproach is also pretty clean i guess
[14:46] <keesj> >>from (tty-added or cua-added) and foo<< does that get interpreted every time an event would come?
[14:52] <Keybuk> the string? no
[14:52] <Keybuk> it's compiled into a match tree in memory
[14:53] <keesj> hmm that you can not replace by lua :)
[14:53] <Keybuk> what would lua gain though?
[14:56] <keesj> in this case nothing. but just like the current script  command you could script the behaviour (if an event is consummed by an handler)
[15:04] <keesj> my system looks a little like the stoplight (the left image) http://smc.sourceforge.net/Images/SmcEx4_Stoplight.png I get the same type of events (like a timeout ). I see very whell how to perform the "start,turn light etc" .
[15:05] <keesj> you get the same "message" but want to perform something different(if you want me to stop just say so  , I am really trying to find a awy to do it)
[15:06] <keesj> I have put the different events in an event_handler that performs the few functions
[15:06] <keesj> so I can not emit "switch_from_a_to_b"
[15:08] <Keybuk> hmm
[15:08] <Keybuk> currently Upstart's event matching is more functional than procedural
[15:09] <Keybuk> ie. you describe the state in which the job is running
[15:09] <Keybuk> inside the job itself, you have a shell script, so it's procedural
[15:09] <keesj> Yes , I Have the feeling I really am missing the point :p
[15:09] <Keybuk> I'm not sure I've got the point ;)
[15:09] <keesj> AM I trying to misue the system?
[15:09] <keesj> missue
[15:09] <Keybuk> I'm not quite sure what you're trying to do yet
[15:11] <keesj> in a perfect work I would like to say "emit go_into_mass_storage" where ever you come from
[15:12] <Keybuk> you wouldn't use an event like that
[15:12] <Keybuk> I'd define mass_storage as a state/job
[15:12] <Keybuk> so "start mass_storage"
[15:14] <keesj> yes I have this part http://paste-it.net/6595
[15:15] <keesj> so do I need to create a userland progress saying "emit stop_mass_storage" "emit start_video"
[15:17] <keesj> with just the start/stop the system looks like /etc/init.d/mass_storage [start|stop]
[15:18] <keesj> or would start mass_storage stop video?
[15:19] <keesj> the backwards compatible scripts use wmtp to "know" what the current runlevel is
[15:29] <keesj> I am getting there ... /initctl list
[15:29] <keesj> shows a list of active tasks, I can only have one state active at the time.....
[15:30] <Keybuk> so you'd make your states start and stop each other?
[15:30] <Keybuk> or be started and stopped by the same events
[15:31] <keesj> I will listen for event use the initctl to know the current state and react as supposed
[15:32] <keesj> I currently implemented it a separate jobs that are triggered by events (the switching between states)
[15:33] <keesj> So I guess the second option
[15:34] <keesj> perhaps I might even use the list to do sanity checks
[15:53] <keesj> I will try to hack a version and try to post it to the list
[16:01] <Keybuk> shiny
[16:05] <keesj> I hope it wil work. (that there are no race cases...)
[16:06] <keesj> it requires a state to keep running apparently a jobs that is started and exits is in a "stop" state again
[16:14] <Keybuk> (gdb) p *((EventOperator *)job->start_on->node->left)
[16:14] <Keybuk> $5 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH,
[16:14] <Keybuk>   value = 0, name = 0x662670 "wibble=foo bar", env = 0x0, event = 0x0,
[16:14] <Keybuk>   blocked = 0}
[16:14] <Keybuk> (gdb) p *((EventOperator *)job->start_on->node->right)
[16:14] <Keybuk> $6 = {node = {parent = 0x662720, left = 0x0, right = 0x0}, type = EVENT_MATCH,
[16:14] <Keybuk>   value = 0, name = 0x6628a0 "wobble=foo bar", env = 0x0, event = 0x0,
[16:14] <Keybuk>   blocked = 0}
[16:14] <Keybuk> (tangent:
[16:14] <Keybuk>  damn I was on good form when I wrote this, I predicted I'd need something a year down the line)
[16:14] <Keybuk> that was from
[16:15] <Keybuk> "wibble=foo bar" or wobble="foo bar"
[16:15] <Keybuk> so it handles quoting sensibly
[16:21] <keesj> can I get the event name inside my scripts?
[16:22] <keesj> UPSTART_EVENT...
[16:22] <Keybuk> right
[16:22] <Keybuk> $UPSTART_EVENTS in trunk
[16:33] <keesj> week-end here. thanks a lot for the help!
[16:33] <Keybuk> enjoy
[16:33] <keesj> thanks


[00:03] <spm> teferi: what was the question number for your GPG request? I'll assign to our group so it doesn't get forgotten :-)
[00:03] <teferi> spm: 51184
[00:03] <wgrant> spm: I suspect that merging the accounts is the solution.
[00:03] <teferi> spm: I obviously still have the key and can do whatever is necessary to prove that I own it
[00:05] <teferi> spm: thanks again
[00:05] <spm> teferi: thank me when it's done ;-)
[00:05] <teferi> i've got a package (and another in the works) all set and ready to dput up, this is the last thing standing in my way
[00:22] <spm> teferi: give that  whirl?
[00:22] <spm> I'm about to be afk for a bit - so will chase any further woes on return :-)
[00:23] <teferi> ok, let's try adding the key again
[00:23] <teferi> oh, oh man!
[00:23] <teferi> thanks!
[00:24] <spm> wgrant: yeah merge is the solution. Is more a matter of dotting i's and crossing t's. So to speak :-)
[00:24]  * teferi waits for a response from ppa
[00:26] <wgrant> spm: Right, but surely it's easy with a request signed by the original user's OpenPGP key...
[00:27] <wgrant> teferi: Have you got an email yet?
[00:27] <teferi> upload accepted
[00:27] <teferi> thanks a lot, spm
[00:28] <wgrant> Excellent.
[00:31] <jml> RAOF: http://robrohan.com/2006/10/19/emacs-key-bindings-on-ubuntu/
[00:32] <teferi> oh dear, where are my binary packages? :P
[00:33] <wgrant> teferi: Have they finished building? If so, when?
[00:33] <teferi> yes, they just finished
[00:33] <teferi> but it still says zero binary packages and zero source packages
[00:33] <wgrant> They'll be visible in 7 minutes
[00:33] <teferi> ah, *nod*
[00:33] <teferi> thanks
[00:33] <wgrant> Binaries and sources are published every 20 minutes.
[00:34] <teferi> would be nice to update https://help.launchpad.net/Packaging/PPA wi th that
[02:20] <spm> wgrant: re key signing. It Depends. Part of the issue was that the old account in question had been manually killed. "why?" becomes the question.
[02:20] <spm> The other side is that crypto only secures the .. path. It doesn't secure the ends.
[02:21] <spm> Was a real PITA trying to convince DSD of that.... anal retentive crypto; but if you have root access at either end. Who cares.
[02:22] <spm> If you're ever feeling really bored and over your exams (hope they're going well btw!) I can bore you to tears on this stuff.
[02:26] <wgrant> That's a good point?
[02:26] <wgrant> DSD?
[02:26] <jml> spm: DSD needed convincing of that!?
[02:26] <wgrant> (having a break from studying to fix fallout from the power failure that knocked me off Freenode... the server here got rather displeased)
[02:27] <jml> spm: man, to think I thought of working there at one point.
[02:27]  * jml waves hi to clipper
[02:27] <spm> wgrant: Defence Signals Directorate: http://www.dsd.gov.au/
[02:28] <wgrant> Ah. .gov.au.  Nuff said. :-)
[02:28] <wgrant> And then we've got Senator Conroy...
[02:29] <jml> who has received a letter from me, pleading for sanity
[02:29] <wgrant> Excellent.
[02:29] <spm> We used to live in the real world of actually solving problems; DSD live in the world of stopping anyone from doing anything.
[02:29] <wgrant> I don't think it will work, though.
[02:29] <wgrant> They seem pretty damn serious.
[02:29] <jml> wgrant: no, it won't.
[02:29] <spm> wgrant: Um. They are :-)
[02:29] <jml> wgrant: http://life.mumak.net/2008/10/how-to-write-to-mp.html
[02:29] <spm> And that's about as much about what they do as I'm going to tell - I have no desire to be locked up for 20 years. ;-)
[02:30] <ajmitch> oh do tell :)
[02:30] <spm> jml: posted mine yesterday - finally.
[02:30] <jml> spm: good on you
[02:31] <wgrant> Maybe iiNet's trials will knock some sense into them.
[02:31] <wgrant> We can hope...
[02:31] <jml> oh, is iiNet trialling it?
[02:31] <spm> Chose to write direct to my MP (Bob McMullan) at his local office vs his APH office. "You are my MP sir..."
[02:31] <spm> jml: you haven't read their CEO's ... rant?
[02:31] <ajmitch> here we're just battling insane copyright changes
[02:31] <spm> or quotes there of? Is most impressive
[02:31] <jml> my main gripe about the whole thing is that if Australians wanted it and if it was commercially feasible, we'd be doing it already.
[02:31] <wgrant> They're going to ask if they can trial it, so they can show that is is broken by design.
[02:32] <jamesh> jml: an extra step in that list would be to check to see if the stamps you have are still the right denomination
[02:32] <jml> spm: no, I haven't. URL?
[02:32] <jml> jamesh: heh heh.
[02:32] <wgrant> jamesh: They didn't publicise that change too well.
[02:32] <spm> jml: errr - lets see if I can find it - been an amazing series of threads on this on the sage-au lists
[02:32] <jml> oh wow, sage.
[02:33] <wgrant> http://www.theage.com.au/news/technology/biztech/net-censorship-plan-backlash/2008/11/11/1226318639085.html
[02:33] <spm> wgrant: ta - jml that's it.
[02:33] <jamesh> jml: http://www.theregister.co.uk/2008/11/12/aussie_firewall_row/
[02:33] <wgrant> That too.
[02:33] <jamesh> the iiNet boss says he'll implement it but publicise how much it slows things down and every time someone bypasses the filters
[02:34] <wgrant> Yep.
[02:34] <spm> If mark newton wasn't raising such a fuss, I'd be tempted to switch to iinet on that alone. ;-)
[02:36] <jamesh> it'd be nice if the stamps were "postage for one letter within Australia" rather than 50c or 55c or whatever
[02:37] <wgrant> spm: Who are you with now?
[02:38] <spm> wgrant: ?? my IRC name doesn't give that away? Internode.
[02:38] <wgrant> kiko: Did you end up rediscovering who was doing the bug scraping, or shall I reinform you?
[02:38] <wgrant> spm: Oh, forgot you weren't cloaked like the rest of the LP people.
[02:45] <DBO> launchpad gave me a permission denied error on my pubkey earlier
[02:45] <DBO> it works fine now
[02:45] <DBO> wtf?
[02:49] <jml> DBO: it's possible that some sort of intermittent network failure occured in the data centre
[02:49] <jml> DBO: or it could be a local config issue on your end
[02:49] <DBO> it works now and all I did was go to dinner =P
[02:49] <jml> DBO: dining is known to solve many problems.
[02:50] <DBO> jml, that would explain it
[03:22] <jml> barry: :P
[03:43] <wgrant> ~>
[03:43] <wgrant> Grr.
[04:38] <newz2000> Hi, I'm trying to upload code to share with a newly created team but it gave me an error that teams cannot have junk branches. What's the best way to share code?
[04:50] <spiv> Make a project for it.
[04:53] <newz2000> hi spiv, if I'm working on a project that has multiple sub-projects should each sub-project be a project in launchpad or can I upload several different (not-related) branches of code to one project?
[04:55] <newz2000> for example, say my project has some code, a website and some docs, each maintained by a diff person. Should that be three different launchpad projects or just one with three different branches?
[04:55] <spiv> newz2000: you can do either
[04:56] <spiv> newz2000: I'd probably lean towards having just one project.
[04:56] <spiv> You can always make new projects and move the branches later if you want.
[04:56]  * wgrant would just have one branch, too.
[04:56] <newz2000> ah, ok. That sounds good, i'll try it now.
[04:57] <newz2000> is it bad form to have a project and team with the same name?
[04:58]  * wgrant looks at launchpad and ~launchpad, and suggests that if they're doing it, it can't be wrong.
[04:58] <newz2000> good point
[04:58] <jamesh> or ~storm and storm
[04:58] <jamesh> or many others
[05:01] <newz2000> I got a javascript error when I clicked "Other/Proprietary" license. setLicensePendingStatus is not defined
[05:01] <newz2000> fyi
[05:51] <Hobbsee> do we have a community help contact yet today?
[05:53] <wgrant> Not at this hou.
[05:53] <wgrant> +r
[05:53] <wgrant> -bad keyboard
[05:54] <Hobbsee> oh yeah, it's still early now, due to DST..
[05:55] <wgrant> Assuming no swaps, it's bigjools today, so it's another 3 hours at least.
[05:56] <cprov> Hobbsee: anything I can help ?
[05:56] <Hobbsee> cprov: no, thanks, it's not soyuz related.
[05:56] <Hobbsee> cprov: but i'd like to know more on the magic diff tool :)
[05:56]  * Hobbsee filed a ticket, requesting someone be unsubscribed from a bug
[05:57] <Hobbsee> er... OOPS-1048EA41 & Error ID: OOPS-1048ED59 ?
[05:57] <cprov> Hobbsee: which `magic diff`  ? we have so many magic components.
[05:58] <Hobbsee> cprov: https://bugs.launchpad.net/bugs/48539
[05:58]  * wgrant would like a button to request an arbitrary debdiff.
[05:58] <wgrant> But I guess Hobbsee wants debdiffs in the queue.
[05:58] <Hobbsee> both would be good :)
[05:58] <cprov> those things are actually easy to implement
[05:58] <Hobbsee> but yes, the queue stuff is what i'd particularly love
[05:58] <Hobbsee> cprov: can we have it for the next release then please?  :D
[05:59] <Hobbsee> would make reviewing much easrier
[05:59] <cprov> right
[05:59] <cprov> Hobbsee: how is the queue-ui doing for you ?
[06:00] <Hobbsee> cprov: pretty good.  Modulo any timeouts of course.
[06:00] <Hobbsee> cprov: it's a bit limiting if you want to accept lots of langpacks, though.
[06:00] <Hobbsee> (because there's no "select all" checkbox)
[06:01] <cprov> yes, we all like gmail ;)
[06:01] <Hobbsee> otoh, i think i can only accept 8(?) at a time anyway, so maybe it's a good thing there's no checkbox
[06:03] <cprov> damm slow.
[06:04] <Hobbsee> hm?
[06:06] <Hobbsee> cprov: on the subject of gmail, have you tried mobile gmail?  From memory, i don't think that actually has checkboxes.
[06:07] <cprov> Hobbsee: yes, but I don't remember how it deletes multiple messages.
[06:07] <cprov> s/deletes/selects
[06:08] <Hobbsee> i don't think it does :)
[06:09] <Hobbsee> in fact, you can't even clear out all spam.
[06:11]  * Hobbsee wonders what https://bugs.edge.launchpad.net/ubuntu/+bug/297388 actually is, and why she wanted to load it
[06:11] <cprov> Hobbsee: ehe, bug or feature ?
[06:11] <Hobbsee> oh, well, that's no help then.
[06:11] <Hobbsee> cprov: well, i'd guess bug :P
[06:11] <Hobbsee> cprov: although possibly feature, based on how they want to keep all mail
[06:12] <cprov> Hobbsee: pretty much as we keep all *your* packages.
[06:12] <Hobbsee> cprov: that's true.
[06:13] <wgrant> That's the bug where spm was a bit over-deletionist.
[06:13] <Hobbsee> ahhh.
[06:13] <Hobbsee> is it supposed to be so over-deleted that it's oopsing out?
[06:13] <wgrant> And that is some *odd* capitalisation.
[06:13] <spm> Hobbsee: Not as such no...
[06:13] <wgrant> I don't think so, but it has been since a couple of minutes after it was mentioned here.
[06:14] <Hobbsee> spm: is it worth filing as a question, or do they all get looked at anyway?
[06:14] <wgrant> The bugtask seems to have vanished, which would explain why it oopses.
[06:14] <Hobbsee> the weird thing is...it's a quick oops.  it's not a timeout.
[06:14] <spm> Hobbsee: it surely can't hurt - if only that we don't lose it - but I'll probably be chasing myself tomorrow as well.
[06:15] <Hobbsee> wgrant: i thought those showed up as differnet oopses (like "lp can't find the page you were looking for")
[06:15] <wgrant> The bug exists.
[06:15] <wgrant> The bugtask does not.
[06:15] <Hobbsee> cprov: sweet :)
[06:15] <spm> 'bugs' within the DB are a lot more complicated that I earlier thought - and we head smashed pretty hard into those complications
[06:15] <Hobbsee> oh, right.  I see.
[06:15] <wgrant> Heh.
[06:16] <spm> 'heh' doesn't even get close to describving the cursing :-)
[06:16] <wgrant> I suppose there are subscriptions and notifications and blah blah that need deleting.
[06:16]  * Hobbsee throws spm a few red snakes (as in, the lollies) for breaking it
[06:16] <spm> pretty much
[06:16] <wgrant> ON DELETE CASCADE!
[06:16] <spm> oh gawd - *more* sugar. :-) Has been a bit of a sugar overload day for me... suspect I'll be bouncing off walls for hours yet.
[06:17] <Hobbsee> spm: well, you could save them for tomorrow :P
[06:17] <spm> wgrant: I just look after things - db decisions are not my problem.  Nor in your hand either.
[06:19] <Hobbsee> spm: no, don't do that.
[06:19] <Hobbsee> spm: you will regret that
[06:19] <spm> snakes to a small child? as in.
[06:19] <Hobbsee> well, sending them on a sugar high, at all
[06:26] <spm> heh. Trust me - a sugar high is not something we try to put him on - the come down is painful all round :-)
[06:26] <Hobbsee> heh heh heh.  yes.
[07:32] <Mez> flacoste: hello :D
[07:33] <Mez> I guess that my arguments for the OpenID thing swayed you :D yay :D
[07:37] <wgrant> What's the solution? Don't stop people from shooting themselves in the foot if they decide to use their sensible LP OpenID?
[07:40] <Mez> possibly... I don't know what they've decided, but they're going to be allowing the "sensible" LP OpenID
[07:40] <Mez> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/294634
[07:41] <Mez> !botsnack
[07:42] <Mez> good bot
[08:44] <kripken> I am having no luck uploading large (30MB) release files to Launchpad. After a while, it always says "Sorry, there was a problem connecting to the Launchpad server." Is it just me?
[08:49] <thekorn> flacoste: thanks for fixing the API on staging
[10:32] <Hobbsee> wow!
[10:33] <Hobbsee> who did the work on the package field, when changing a bug to a different package?  It actually shows the binaries for each of the sources now!
[11:42] <savvas> hello, does anyone know how to provide a gpg key for my PPA?
[11:43] <bigjools> savvas: do you mean https://bugs.edge.launchpad.net/bugs/125103 ?
[11:44] <savvas> I'm getting the "Warning: The following packages could not be authenticated:" error
[11:44] <savvas> ah thanks bigjools
[11:44] <bigjools> savvas: yes that's normal, see the bug :)
[11:44] <Hobbsee> bigjools: oh, interesting fix.
[11:44] <mpt> wgrant, wow, you've been hitting the "Report a bug" button pretty hard :-)
[11:45] <Hobbsee> mpt: that's a feature :P
[11:45] <bigjools> mpt: harder than you? surely not :)
[11:45] <wgrant> mpt: Erm, yes. I do that occasionally.
[11:45] <mpt> good work
[11:45]  * Hobbsee has been fixing bugs instead
[11:45] <wgrant> But I then get told I should have hit it harder and split them up :P
[11:47] <mpt> Hm, yeah, I don't think bug 297531 should have been marked incomplete
[11:48] <wgrant> I would have thought those things could all be most easily done in one hit, which was why I put it in one bug.
[11:48] <bigjools> Hobbsee: probably the only sane fix
[11:48] <Hobbsee> bigjools: indeed.
[11:50] <mpt> Compare bug 253317, reported by our erstwhile project manager :-)
[11:51] <wgrant> Yay, silbs.
[11:51] <wgrant> silbs wants to bring QA sanity to bug statuses.
[11:51] <wgrant> mpt: Ahaha, nice.
[11:53] <wgrant> Oh yeah, most of the teams involved in bug #297505 are Canonical-related.
[11:55]  * wgrant hopes you can't ignore silbs.
[11:55] <wgrant> I like the last three bugs.
[11:58] <wgrant> mpt: Is there a reason that Bug/+subscribe survived your reign with a single option button with continue/cancel buttons, rather than just Subcribe and Cancel buttons?
[11:59] <mpt> wgrant, lack of person-hours mostly, there are bug reports on both those things
[12:00] <wgrant> Right, as long as it wasn't intentionally kept.
[12:00] <mpt> nooooo
[12:01] <mpt> definitely not
[12:01] <wgrant> Good, good.
[12:20] <NCommander> Is sparc's other builder ever going to return?
[12:22] <bigjools> NCommander: I don't know, let me find out
[12:23] <NCommander> bigjools, thank you. I'd be depressed to see sparc die as an architecture due to dead builders
[12:23] <wgrant> I wonder if hppa will catch up before armel does.
[12:24] <NCommander> someone take a screenshot, we'll never see a build queue over 8,000 again until after the next port is bootstrapped
[12:26] <bigjools> :)
[12:46] <persia> Sometimes we get close when we open a new release archive, but that's admittedly usually only in the 4000 range.
[12:47] <danilos> mdke: hey, if you've got time, I'd like to check if fix for bug #282695 is correct, can you please browse to https://translations.staging.launchpad.net/ubuntu/intrepid/+source/ubuntu-docs and see if link "Download translations" works for you (I've removed you from the ubuntu-translation-coordinators team on staging only :)
[12:53] <joshuablount> Morning lp:~people
[12:54] <joshuablount> Is there a good way to programmatically tell what bug emails are for what project? I'm setting up some rules for thunderbird to sort incoming stuff, but there doesn't seem to be anything about the project a bug is related to in the emails...
[12:54] <salgado> joshuablount, have you checked the X-Launchpad header?
[12:55] <wgrant> X-Launchpad-Bug: product=yourprojectnamehere
[12:56] <joshuablount> salgado, wgrant: I spoke to quickly, just noticed this.
[12:56] <joshuablount> Thanks!
[12:56] <salgado> np
[12:56] <bigjools> NCommander: some hardware died, it's being sorted out.
[12:57] <NCommander> wooo
[13:21] <geser> can somebody tell me why LP thinks that r-cran-fimport got superseded? see https://edge.launchpad.net/ubuntu/jaunty/i386/r-cran-fimport/+index
[13:21] <geser> no published version anymore of it
[13:21] <geser> it's an arch:all package
[13:22] <geser> and got binary NEWed yesterday
[13:22] <danilos> mdke: never mind that, I've managed to test this myself, thanks :)
[13:41] <NCommander> bigjools, I've got an LP question
[13:41] <NCommander> bigjools, well, SOyuz, more specifically
[13:42] <NCommander> bigjools, can Soyuz pin a repo to pin priority 200 (in the Release file), so a repo could be enabled, but nothing installed by default?
[13:44] <bigjools> NCommander: why would you want to do that?
[13:45] <NCommander> bigjools, there is some talk about changing how the Backports repo works in this respect, essentially because pinning is PITA to do with APT, I'm hoping for the Jaunty cycle to implement some mechanism to allow a backport installation without having to install the entire repo
[13:45] <NCommander> sorta like a graphical frontend to apt-get -t hardy-backports install *backport*
[13:45] <NCommander> I wanted to know from a technical perspective if this was even possible
[13:46] <bigjools> NCommander: I don't see why not, it's just meta data about the archive right?
[13:46] <NCommander> Its a line in the Release file if memory serves
[13:51] <mfoniso> I'm trying to import my ssh keys into launchpad, but it keeps getting refused, with the message that the keys are "...known to be compromised"
[13:52] <bigjools> mfoniso: you need to generate new keys
[13:52] <mfoniso> I'm on ubuntu and have reinstalled the openssh suite, regenerated new ketys
[13:52] <mfoniso> but they still don't work
[13:53] <mfoniso> bigjools: how do I go about that, 'cos I still encounter the same problems after generating new keys
[13:53] <bigjools> mfoniso: are you sure you're sending the new keys?
[13:53] <bigjools> completely remove the old ones, they are worthless
[13:54] <mfoniso> I'm pretty sure I'm sending the new keys, and I did remove all the old stuff..
[13:54] <mfoniso> in fact, I deleted everything in ~/.ssh/ just to make sure
[13:54] <mfoniso> uninstalled openssh (since it was a supposed compromised version)
[13:54] <bigjools> that message can only happen if ssh-vulnkey says it's a bad key
[13:54] <mfoniso> reinstalled ssh and generated new keys
[13:54] <bigjools> try that locally and see what it says
[13:55] <mfoniso> ssh-vulnkey says "Unknown (no blacklist information)..."
[13:57] <mfoniso> ok, the ubuntu security advisory says to destroy the key and create a new one, lemme try that  (again)
[13:58] <mfoniso> bigjools: does deleting the public and private keys should accomplish said destruction?
[13:58] <bigjools> mfoniso: unless you have any more copies, yep
[13:59] <flacoste> thekorn: my pleasure, sorry, that it took so long
[13:59] <flacoste> Mez, wgrant: yeah, the OpenID to use with launchpad will be the profile page
[14:00] <mfoniso> ok
[14:00] <flacoste> Mez: and yes, your social argument about the "social" aspect of the identity really made the difference
[14:01] <flacoste> Mez: our OpenID system was really designed as a single-sign on system, which is different, fortunately, the two aspects can work with each other through the magic of delegation
[14:02] <mfoniso> bigjools: I just deleted id_rsa and id_rsa.pub, created new keys (via ssh-keygen) launchpad still gives the sames message
[14:03] <bigjools> mfoniso: that is odd
[14:03]  * mfoniso thinks so too
[14:03] <mfoniso> I've done this over and over
[14:03] <mfoniso> I have no idea what I'm doing wrong
[14:03] <bigjools> mfoniso: the code in LP that checks it is calling ssh-vulnkey (I have the code in front of me)
[14:03] <bigjools> mfoniso: so it's still seeing your old key somehow
[14:04] <mfoniso> but why?
[14:04] <bigjools> mfoniso: do you have any id_dsa keys?
[14:05] <mfoniso> nope
[14:06] <bigjools> hmmm
[14:07] <persia> mfoniso, What happens when you try ssh-vulnkey on your local system?
[14:08] <bigjools> he did alreadu
[14:08] <bigjools> already
[14:09] <mfoniso> no blacklist information
[14:09] <mfoniso> the ubuntu security advisory says in this scenario, to create new keys
[14:10] <bigjools> mfoniso: and you're definitely pasting the contents of your new ~/.ssh/id_rsa.pub file?
[14:10] <persia> mfoniso, do you have openssh-blacklist and openssh-blacklist-extra installed?
[14:10] <persia> bigjools, Which blacklist files does LP use?
[14:11] <bigjools> persia: whatever Hardy has installed
[14:11] <bigjools> persia: it uses ssh-vulnkey
[14:11] <persia> bigjools, Yep, and ssh-vulnkey relies on blacklist files.
[14:12] <persia> I don't think they are force-installed for every machine though.
[14:12] <mfoniso> bigjools: yeah, pasting the contents of ~/.ssh/id_rsa.pub
[14:12] <mfoniso> persia:I don't have those installed
[14:13] <mfoniso> I know they were there initially
[14:13] <mfoniso> but I did a couple of uninstalls/installs
[14:13] <persia> mfoniso, Try installing just openssh-blacklist and see if ssh-vulnkey says something different.
[14:13] <mfoniso> they aren't there right now
[14:13] <bigjools> mfoniso: can you try generating a DSA one instead?
[14:13] <mfoniso> it'll say COMPROMISED.. but I'll do it anyway
[14:13] <mfoniso> bigjools: ok
[14:15] <mfoniso> bigjools: same message from LP
[14:15] <bigjools> mfoniso: what version of openssh are you using?
[14:15] <mfoniso> persia:funny... apt-get says "openssh-blacklist is already at newest version"
[14:16] <mfoniso> ssh -v gives me : "OpenSSH_4.6p1 Debian-5ubuntu0.6, OpenSSL 0.9.8g 19 Oct 2007"
[14:16] <bigjools> mfoniso: can you pastebin me the public key you're using
[14:17] <mfoniso> bigjools: ok, and it appeas my version of openssh isn't the latest version...
[14:17] <mfoniso> i expected that "apt-get install" would grab the latest version
[14:18] <bigjools> mfoniso: are you on intrepid?
[14:18] <mfoniso> nope
[14:18] <mfoniso> hardy
[14:18] <mfoniso> can't upgrade just yet, I'm currently on a slow connection
[14:18] <bigjools> mfoniso: my hardy box has OpenSSH_4.7p1
[14:19] <mfoniso> if I uninstall openssh, and reinstall it via apt-get, would that get the latest version?
[14:19] <bigjools> it should upgrade anyway
[14:19] <mfoniso> or does that depend on the sources in my sources file?
[14:19] <bigjools> yes - what do you have enabled?
[14:20] <mfoniso> everything :-)
[14:21] <mfoniso> hey hey hey... LP just accepted the key I was about to paste for you.. and it's the same key I tried a while ago ...
[14:21] <bigjools> !
[14:21] <mfoniso> but I don't feel comfortable not knowing what's going on
[14:21] <bigjools> you need to upgrade openssh-client BTW, not openssh
[14:22] <mfoniso> ok
[14:22] <mfoniso> I just noticed something...
[14:22] <persia> The version in hardy should be fine.  No need to upgrade.
[14:23] <mfoniso> the public key starts like so "ssh-rsa AAAAB3Nza..."
[14:23] <bigjools> persia: well he doesn't have the latest
[14:24] <mfoniso> when I paste it in LP, the text right after "ssh-rsa" get moved to a new line...
[14:24] <mfoniso> as though the space is converted to a newline
[14:24] <mfoniso> and I think that's what's happening (as opposed to the display just being wrapped)
[14:25] <mfoniso> and LP complains when I try to upload it
[14:25] <persia> 4.6p1 is the version from 7.10 (gutsy).  Odd.
[14:25] <mfoniso> but it accepts it after I manually remove the space, and add it again with spacebar.
[14:26] <bigjools> mfoniso: copy & paste - gotta love it
[14:26] <mfoniso> thanks for your time guys, I really appreciate it
[14:26] <bigjools> you're welcome
[14:27] <mfoniso> but I still wanna see what ssh-vulnkeys has to say...
[15:49] <gnomefreak> anyone give me a hint why my merge request was rejected?
[15:49] <beuno> gnomefreak, URL?
[15:49] <gnomefreak> beuno: one sec
[15:51] <gnomefreak> beuno: merging https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu into ~dev branch let me get full name of branch
[15:52] <gnomefreak> https://code.edge.launchpad.net/~ubuntu-dev/firefox-extensions/firegpg.ubuntu
[15:52] <beuno> gnomefreak, https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu/+merge/1671
[15:52] <gnomefreak> oh
[15:52] <gnomefreak> beuno: why did i get rejection email
[15:52] <gnomefreak> and my proposed merge 4 emails
[15:53] <beuno> gnomefreak, uhm, can you forward it to me?
[15:53] <beuno> you shouldn't get reject emails
[15:53] <gnomefreak> beuno: yep need address
[15:53] <beuno> gnomefreak<EMAIL_ADDRESS>[15:54] <gnomefreak> ok ill send you rejection one any of the rest?
[15:54] <beuno> just the rejection one
[15:54] <beuno> I don't know why you got 4, but 2 is normal
[15:55] <gnomefreak> beuno: 2 was me requesting and one was lp and other was reject. so i sent you only the important one
[15:55] <gnomefreak> universe-bugs is rejection email
[15:57] <beuno> gnomefreak, hm, the mailing list is rejecting the email
[15:57] <beuno> maybe the email list is set as the contact address for the team that owns the trunk?
[15:57] <gnomefreak> beuno: should it be?
[15:58] <gnomefreak> its  a ~ubuntu-dev branch not sure what universe has to do with LP branches since branch doesnt say universe or main or any of the above
[15:58] <beuno> gnomefreak, well, I don't know, but I do know that if these emails get sent to a list it isn't subscribed to, then the mailing list will reject them
[15:58] <beuno> so it's not really Launchpad rejecting
[15:59] <gnomefreak> ok thanks ill find out why the list
[15:59] <beuno> np
[16:44] <Mez> flacoste: Yeah, but as I said, to me, it's not an identity if it's used just for signon...
[16:45] <flacoste> Mez: right
[20:10] <xlyz> anyone kowns how to download updated translations from launchpad with bzr?
[21:12] <spm> wgrant: OT for channel: http://today.ninemsn.com.au/videoindex.aspx 'firewalls under fire' - Mark Newton was interviewed this morning by Today. Enjoy, or not :-)
[21:13] <fta>  * State: Chroot problem
[21:13] <fta>  * Architecture: lpia
[21:13] <fta>  * Archive: fta PPA
[21:13] <fta> logs say "FATAL: kernel too old"
[21:14] <fta> (jaunty)
[21:15] <persia> fta, Known issue.  Attempts have been made to fix it (although perhaps not entirely successful).  Try a rebuild.  If that doesn't work, ignore it for a bit.
[21:16] <fta> ok, thanks
[21:44] <wgrant> spm: Ew, I've now watched a segment of Today. I feel dirty.
[21:44] <spm> wgrant: spray-n-wipe your eyeballs? ;-)
[21:45] <wgrant> But it was actually a fairly sane interview.
[21:45] <wgrant> Surprising.
[21:46] <spm> yeah - apparently should be some stuff in the 7.30 report sometime next week too. Interesting times...
[21:46] <wgrant> matsubara_: "might be disclosing"... oh, you are. It's fairly interesting too.
[21:46] <wgrant> Good.
[21:47] <wgrant> Most ppeople still aren't aware...
[21:48] <matsubara_> wgrant: ?
[21:49] <wgrant> matsubara_: The mailing list privacy thing.
[21:49] <spm> wgrant: I've seen some... "challenging" discussions around the lack of comment from the ACS as well. Cynical me is not surprised, but it's an "interesting" (in the Yes Minister sense) non-position for them to take.
[21:49] <matsubara_> ah right.
[21:52] <wgrant> OTOH LP people seem to like making completely harmless bugs private.
[21:53] <wgrant> It doesn't even contain a snippet of code or design.
[22:30] <fta> persia, it's now on i386 too (iridium), retry doesn't help
[22:30] <fta> http://launchpadlibrarian.net/19627521/buildlog_ubuntu-jaunty-i386.liferea_1.4.18-0ubuntu3%7Efta1_CHROOTWAIT.txt.gz
[22:30] <persia> fta, Hrm.  Dunno what to say then.  It's probably not really fixed.
[22:30] <fta> obviously
[22:30] <wgrant> I'm sure infinity will sort it out soon.
[22:31] <fta> http://launchpadlibrarian.net/19625242/buildlog_ubuntu-jaunty-lpia.xulrunner-1.9.1_1.9.1%7Eb2%7Ehg20081113r21632%2Bnobinonly-0ubuntu1%7Efta1_CHROOTWAIT.txt.gz


[12:19] <daviey> Hi, can somebody tell me how to resize an image in gimp so it squeezes it
[12:20] <daviey> ie, save a 16:9 picture into a 4:3 resolution (makeing things tall)?
[12:56] <kwwii> scale the image
[12:56] <kwwii> only deselect the little link next to the sizes in the pop-up before you change anything
[12:59] <kwwii> ie. in gimp
[01:27] <daviey> kwwii, thanks - did that
[01:27] <daviey> worked a treat
[01:27] <daviey> ;)
[01:27] <kwwii> ;-)
[05:02] <mjunx> hey, is there any reason why beryl screws up the kicker system tray?
[05:02] <mjunx> normally it can stack two rows of icons
[05:02] <mjunx> but whenever I run beryl, it doesn't
[06:28] <sarracenia88> hello
[08:22] <nysosym> hi there :)


[00:22] <Bashing-om> https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Faster-Linux-Boot-PADATA - Interesting; Pertains to the 5.8 kernel inclusion - wonder how we can make it as current general interest.
[00:35] <guiverc> Bashing-om, I finished wiki read thru, my only comment was xubuntu/Xubuntu change
[00:37] <guiverc> the oracle patch article looks good, it's other news to me though
[00:48] <Bashing-om> guiverc: Agreed - think important enough to "make it so" this issue; even though will not see it Generally Available for some time.
[00:49] <guiverc> yeah it was very interesting, would be very reader-appreciated I bet..
[01:09] <Bashing-om> UWN: Linux-Boot-PADATA patch article added :D
[01:17] <guiverc> yep looks good Bashing-om
[01:17] <Bashing-om> guiverc: Not to shabby ^ for a rush job :P
[01:18] <guiverc> :)
[08:00] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Valve Drops SteamVR for macOS, as Linux and Windows Now the Key Focus @ https://news.softpedia.com/news/valve-drops-steamvr-for-macos-as-linux-and-windows-now-the-key-focus-529884.shtml (by Bogdan Popa, Microsoft News Editor)
[08:47] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: Managed OpenStack cheaper than self-managed? @ https://ubuntu.com/blog/managed-openstack-cheaper-than-self-managed
[11:14] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: How to upgrade from Ubuntu 18.04 LTS to 20.04 LTS today @ https://ubuntu.com/blog/how-to-upgrade-from-ubuntu-18-04-lts-to-20-04-lts-today
[15:38] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: This VLC Skin Helps the Media Player Look at Home on Ubuntu 20.04 @ https://www.omgubuntu.co.uk/?p=176431 (by Joey Sneddon)
[18:07] <Bashing-om> Still awaiting the availibility of .ISOs - else I pull * Ubuntu 20.10 (Groovy Gorilla) Daily Builds Are Now Available for Download, shortly.
[19:28] <Bashing-om> UWN: Pulling "WIP" and the (Groovy Gorilla) Daily Builds link. Time to push 20:00 GMT.
[19:44] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: Enhanced SSH and FIDO authentication in Ubuntu 20.04 LTS @ https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication-in-ubuntu-20-04-lts
[19:59] <Bashing-om> UWN: news@lists is away - doing the forum post next.
[20:13] <Bashing-om> UWN: Forum post done - update sections abridged for excessive content.
[20:16] <Bashing-om> UWN: Doing the re-directs.
[20:24] <Bashing-om> UWN: re-directs done. Pending are the social media postings :F
[21:49] <Wild_Man> Hi Bashing-om
[21:49] <Wild_Man> I will do the fridge and Social Media
[21:50] <Bashing-om> Wild_Man: :D
[22:00] <Wild_Man> http://fridge.ubuntu.com/2020/05/04/ubuntu-weekly-newsletter-issue-629/
[22:02] <Bashing-om> Wild_Man: Fridge: looks good - spot check checks good too :D
[22:06] <Wild_Man> Thanks for checking Bashing-om, all done. I have to go to a couple of other tasks bbl, good work
[22:11] <Bashing-om> Wild_Man: :D
[22:28] -BottyMcBotFace:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 629 @ http://fridge.ubuntu.com/2020/05/04/ubuntu-weekly-newsletter-issue-629/


[07:14] <Guest29> hey guys
[07:15] <Guest29> i have upgraded to ubuntu 21.10 beta and after it i see my scroll in touchpad is so fast and i cant see my toucpad in xinput list i just have it in /proc/bus/input/devices as Name="SynPS/2 Synaptics TouchPad"
[07:15] <Guest29> how can i set a value for my speed in scroll in touchpad
[08:11] <Guest41> hi
[08:11] <Guest41> anyone here?
[08:12] <Guest41> my scroll in touchpad is so fast
[08:12] <Guest41> and i dont have my touchpad id in xinput list
[08:13] <Guest41> i just have it in /proc/bus/input/devices
[08:13] <Guest41> how can i set a value for speed of scrolling in my touchpad
[08:13] <Guest41> ?
[14:52] <tmus> Trying the "new" default Firefox snap version on Impish, it takes a full 15 seconds to launch. Is this because it's a development version or is this the experience going forward? I realize people are complaining about snaps and slowness all the time, and I really don't want to just "howl with the pack". How can we make this better?
[17:58] <lotuspsychje> tmus: usualy for snap bugs, we refer to snap info snapname for the contact/bug link
[17:59] <lotuspsychje> tmus: browsing the latest added bugs is also a good idea, and if yours doesnt list, you can always file a new one
[18:41] <tmus> lotuspsychje, perfect - thank you.
[18:44] <tmus> where are bugs reported for a new ubuntu default, packaged by canonical, published by mozilla, included in ubuntu, but endorsed by mozilla? this is not entirely clear to me... :|
[18:45] <tmus> snapcraft? mozilla? launchpad?