[00:05] <thumper> davecheney: bug 1134959
[00:05] <_mup_> Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >
[00:16] <arosales> davecheney: aroun?
[00:16] <arosales> around, that is :-)
[00:24] <davecheney> arosales: two secs
[00:24] <davecheney> still on the phone
[00:24] <davecheney> thumper: thanks
[00:25] <arosales> davecheney: thanks
[00:30] <arosales> davecheney: when you are free I am using a the following for hpcloud in the environments.yaml file: http://pastebin.ubuntu.com/5572190/
[00:31] <arosales> and I am getting the error error: secret-key: expected nothing, got "<redacted>"
[00:38] <arosales> davecheney: I have tried variations of adding in "tenant-name" and "region" with no sucess
[00:38] <arosales> *success, that is.
[00:39] <arosales> I did get AWS to bootstrap though and deploy wordpress/mysql
[00:41] <davecheney> arosales: just finishing up
[00:44] <davecheney> arosales: tip: remove secret key
[00:44] <davecheney> it isn't used in our juju
[00:44] <davecheney> i think it was optional in 0.6
[00:45] <arosales> access key too?
[00:45] <davecheney> arosales: I usually let those flow through from sourceing .novarc
[00:45] <arosales> davecheney: I am not sourcing a novarc file
[00:46] <arosales> so I think I need them somewhere
[00:48] <arosales> davecheney: aws set up worked, with the keypair access set up. Specifically putting in my access-key and secret-key embedded in the environments.yaml file.
[00:48] <arosales> its just hpcloud environments.yaml file that is giving me guff.
[00:49] <davecheney> arosales: ok, you have my complete attention :)
[00:49] <arosales> :-)
[00:50] <arosales> tldr I can't get hpcloud environment.yaml to work with go-juju
[00:50] <davecheney> i've only tested against canonistack, and I let the valyes flow throught from sourceing my .novarc
[00:50] <arosales> my env.yaml for hpcloud is @ http://pastebin.ubuntu.com/5572190/
[00:50] <davecheney> lets see what I am missing
[00:50] <wallyworld_> arosales: if you have the latest go juju you can run "juju generate-config" and it will give you a boilerplate file
[00:50] <arosales> wallyworld_: thanks, I also tried using that template
[00:51] <davecheney> ^ what wallyworld said
[00:51] <arosales> but no go
[00:51] <wallyworld_> you should just havve needed to change the auth url
[00:51] <wallyworld_> worked for me anyway
[00:51] <arosales> wallyworld_: and add in my credentials
[00:51] <wallyworld_> what version of juj you running?
[00:51] <arosales> wallyworld_: I agree, but alas no bootstrap
[00:51] <wallyworld_> arosales: i just source a nova rc for that so they come from env vars
[00:52] <arosales> wallyworld_: 1.9.9-2~923~quantal1
[00:52] <wallyworld_> ok, latest version then
[00:52] <arosales> wallyworld_: davecheney: so it is a requiment to source a novarc then?
[00:52] <arosales> and if not get breakage?
[00:53] <wallyworld_> no, but if not, you need to have env vars set or edit the yaml
[00:53] <davecheney> arosales: sorry, you've probably done this already, can you paste the output when you do
[00:53] <davecheney> juju bootstrap --debug -e '$YOURENV'
[00:53] <arosales> wallyworld_: I got those creds in the yaml directly
[00:53] <wallyworld_> ok
[00:53] <davecheney> you can use paste.canonical.com for more private stuff
[00:53] <wallyworld_> incl region and tenant etc?
[00:54] <arosales> let me sanitize the output real quick
[00:55] <arosales> davecheney:
[00:55] <arosales> $ juju --debug bootstrap -e hpcloud
[00:55] <arosales> 2013/02/27 18:53:59 JUJU environs/openstack: opening environment "hpcloud"
[00:55] <arosales> 2013/02/27 18:53:59 JUJU juju bootstrap command failed: secret-key: expected nothing, got "<redacted>"
[00:55] <arosales> error: secret-key: expected nothing, got "<redacted>"
[00:56] <davecheney> remove the secret-key line from your enviornment.yaml
[00:56] <davecheney> you may have to remove others
[00:56] <wallyworld_> arosales: can you pastebin your yaml - it seems out of date
[00:56] <davecheney> did generate-config generate this config ?
[00:56] <davecheney> or is this an old one that used to work with 0.6
[00:56] <arosales> davecheney: if I remove the secret key how do I authenticate?
[00:56] <davecheney> secret-key is a noop in our juju
[00:56] <arosales> wallyworld_: http://pastebin.ubuntu.com/5572190/ is my latest env.yaml I made from the boilerplate
[00:57] <wallyworld_> arosales: you sure?
[00:57] <arosales> davecheney: I tried my config from juju-py and it didn't work so I tried with the boilerplate
[00:57] <arosales> wallyworld_:  yes :-)
[00:57] <wallyworld_> ah ok, did you replace the admin-secrect with redacted?
[00:57] <arosales> wallyworld_:  I am crazy most the time, but I just did this ;-)
[00:58] <wallyworld_> it should have been a random nmber of sorts
[00:58] <arosales> wallyworld_: correct, I don't want to post my keys in the public ;-)
[00:58] <arosales> wallyworld_: I did get aws bootstraped, just hp giving me issues.
[00:58] <wallyworld_> auth mode should be userpass i think
[00:58] <davecheney> arosales: go juju does not use the secret-key configuration item
[00:59] <davecheney> you have to remove it
[00:59] <arosales> wallyworld_: for authmod = keypass ?
[00:59] <davecheney> arosales: i don't thikn goose supports that either
[00:59] <davecheney> the only methods it supports is legacy and userpadd
[00:59] <davecheney> userpass
[00:59] <wallyworld_> arosales: what i meant before was that i think an earlier version of the boilerplate did have "redacted" in it
[00:59] <arosales> davecheney: so this is a bug then
[00:59] <arosales> davecheney: I think what you are telling me is I need to have my keys in a novarc, and it _can't_ be embedded in the env.yaml
[01:00] <wallyworld_> arosales: authmode should be userpass
[01:00] <arosales> correct?
[01:00] <wallyworld_> keypair is not supported yet
[01:00] <wallyworld_> for openstack
[01:00] <arosales> really?
[01:00] <arosales> :-(
[01:00] <wallyworld_> not a bug, just not supported
[01:00] <arosales> most folks use keys
[01:00] <arosales> bug for 13.04 by default
[01:00] <arosales> at lest in my opinion
[01:00] <davecheney> arosales: I will raise a bug
[01:00] <davecheney> you are correct
[01:00] <davecheney> the way the configuration works is
[01:01] <davecheney> most items in ~/.juju/environments.yaml
[01:01] <arosales> davecheney: I can open the bug, I just wan't sure if it was pilot error
[01:01] <wallyworld_> arosales: its just that we have not ad the resources to get to it yet
[01:01] <davecheney> will take values from ENV values if they are missing from the yaml file
[01:01] <arosales> wallyworld_: understood, I just wanted to ask more folks to use go-juju and ran into this
[01:02] <arosales> should be noted in the release notes.
[01:02] <arosales> under known bugs
[01:02] <davecheney> arosales: I will make sure it is noted in the next release notes
[01:02] <wallyworld_> userpass works ok with hpcloud :-)
[01:02] <arosales> wallyworld_: ok, I"ll give that a try later tonight
[01:02] <arosales> wallyworld_: davecheney thanks for the help
[01:02] <arosales> davecheney: would you like me to open the bug
[01:02] <wallyworld_> hence we needed to get other stuff working first :-)
[01:03] <davecheney> arosales: yes please
[01:03] <arosales> davecheney: will do
[01:03] <arosales> I'll get that logged later tonight.
[01:03]  * arosales needs to attend to some daddy duty
[01:03] <wallyworld_> arosales: also, i found a showstopper yesterday which we are fixing asap - go juju won't be able to deploy to hp clound until fixed, even once you get your env sorted
[01:03] <arosales> ah, ok
[01:03]  * davecheney thinks he knows what that one is :)
[01:04] <arosales> wallyworld_: could you give me a ping when that lands in the ppa?
[01:04] <arosales> or even to the juju list would be better
[01:04] <wallyworld_> arosales: sorry :-( still a work in progress, trying to get it done asap
[01:04] <wallyworld_> arosales: sure, no problem. aiming for next release hopefully
[01:04] <davecheney> arosales: there is a juju-core-daily ppa
[01:04] <arosales> wallyworld_: thanks
[01:04] <davecheney> which you can use if you're super keen
[01:04] <wallyworld_> arosales: thanks for your patience also, and sorry for the issues
[01:04] <arosales> davecheney: I may have to use that to get the fix
[01:05] <arosales> wallyworld_: no worries part of trying out bleeding edge :-)
[01:05] <arosales> thats part of the fun right?
[01:05] <wallyworld_> oh yes, very bleeding right now
[01:05]  * arosales has to run
[01:05] <arosales> later fellas
[01:05] <arosales> be back online later tonight though
[01:05] <arosales> thanks again
[01:05] <wallyworld_> ok, see ya
[01:05] <davecheney> arosales: thanks for being a beta tester, i'll buy you a chocolate or a teddy bear in Altanta as a boobie prize
[01:06] <wallyworld_> davecheney: so about that mp....
[01:06] <davecheney> wallyworld_: sorry, a lot has scrolled off the screen
[01:06] <wallyworld_> yeah :-) np
[01:07] <wallyworld_> [09:53:17] <wallyworld_> davecheney: hi, a quick clarification on your concern about returning an unexported error
[01:07] <wallyworld_> [09:53:38] <wallyworld_> i coped the pattern used already in the state package for notFoundError
[01:07] <wallyworld_> [09:54:25] <wallyworld_> i guess the original author didn't want people to access anything other than Error() ?
[01:07] <wallyworld_> [09:55:24] <wallyworld_> that fact that we don't need the error exported (it's not used anywhere) - does that imply it can stay as is for now?
[01:07] <davecheney> ahh,yes
[01:07] <davecheney> sorry
[01:07] <wallyworld_> np
[01:07] <davecheney> ok, as I understand it
[01:07] <davecheney> if you return a private type, with a public Error method
[01:07] <davecheney> that satisfied the error interface
[01:08] <davecheney> but callers may not be able to use a type asserting to tell what kind of error it is
[01:08] <wallyworld_> davecheney: there's a helper mthod for that
[01:08] <wallyworld_> IsNotFound()
[01:08] <wallyworld_> IsUNauthorised()
[01:08] <davecheney> having said that, it looks like the method was doing the wrong thing
[01:08] <davecheney> in which case, it does not help to comment that the type of the error will be x (little x, not exported) becuase there is nothing that can be done with that information
[01:09] <davecheney> maybe in return you could replace the text with a hint to pass the error to IsNotFound(err)
[01:09] <davecheney> that was all I ways saying in that comment
[01:09] <davecheney> returning unexported errors is something that gets on peoples' goat in the stdlibrary
[01:09] <davecheney> for example, errClosing
[01:10] <wallyworld_> davecheney: yeah, understood. i have no firm opinion being a Go noob. i was just being consistent with what was already done by someone else for notFounfError
[01:10] <wallyworld_> so i was going for consistency
[01:11] <davecheney> ok, lemmie review again, if you've already got 2 LGTM, then don't wait for me
[01:11] <wallyworld_> davecheney: i don't mind waiting - if there's an idiomatic issue like htis, i'd rather get it sorted instead of having the wrong thing cargo culted. as it is, i copied what was there before
[01:12] <wallyworld_> i assumed that it was done the right way previously for notFound
[01:12] <davecheney> ok, bio break, then review
[01:12] <wallyworld_> davecheney: ok, i have to run an errand, back in a bit and will look
[02:17] <davecheney> wallyworld_: re your CL
[02:17] <davecheney> the previous type, ErrUnauthorized was exported
[02:18] <davecheney> i'll put my comments in the review
[02:46] <wallyworld_> davecheney: it was, but only because it was a var. the other error commonly used in state package, notFoundError, was not exported.
[02:46] <wallyworld_> the implementation has changed from a var to a type, and there's a helper method used to discriminate the error type
[02:47] <wallyworld_> there already is a helper method in the MP too - IsUnauthorised()
[02:48] <wallyworld_> so, i'll add the comment as requested. thanks for looking
[02:49] <davecheney> wallyworld_: SGTM, either of those choices is fine
[02:49] <wallyworld_> ok, np. thanks. i just wanted to be 100% sure you were happy
[02:49] <davecheney> no, thakn you
[02:50] <davecheney> this isn't the end of the world
[02:50] <davecheney> but its nice to go the extra mile
[02:50] <wallyworld_> there's a fair bit of inconsistency in places
[02:50] <wallyworld_> and then it gets cargo culted
[02:50] <davecheney> do you want to raise an issue for the worst offenders
[02:50] <davecheney> otherwise i fear they may never be addressed
[02:51]  * davecheney appologises for sounding like a issue whoring broken record
[02:51] <davecheney> i used to work for an issue tracker company
[02:51] <wallyworld_> i have no real concrete examples - but as i find them again i should keep a list
[02:51] <wallyworld_> it's just a general perception
[02:51] <davecheney> and it was beaten into me that if there was no issue, it didn't happen
[02:51] <wallyworld_> yeah agreed
[02:51] <davecheney> i'd like it if you kept that list in an issue
[02:51] <davecheney> or at a minimum google docs
[02:51] <wallyworld_> sure.
[02:51] <davecheney> on your own workstation isn't helpful
[02:52] <wallyworld_> some of it could be contentious eg error handling
[02:52] <wallyworld_> i have a philosophical difference in opinion with a few others i think
[02:53] <davecheney> even more reason to flush it out into the open
[02:53] <wallyworld_> a list also would determine if my perceptions are real
[02:53] <wallyworld_> perhaps there's not much to it
[02:55]  * davecheney shrugs
[02:55] <davecheney> i dunno how much there is
[02:55] <davecheney> but setting a precident now is important
[03:09] <davechen1y> thumper: excellent proposal
[03:09] <davechen1y> i was going to propose something like that myself
[03:09] <thumper> davechen1y: I was just about to ping you about it :)
[03:09] <thumper> just a little editing and the help one is following
[03:14] <davechen1y> thumper https://bugs.launchpad.net/juju-core/+bug/1134959
[03:14] <_mup_> Bug #1134959: worker/uniter: multiple test failures <juju-core:Triaged> < https://launchpad.net/bugs/1134959 >
[03:15] <davechen1y> how come I didn't get a notification about this one ?
[03:15] <davechen1y> i'm listed as the bugmaster on this project
[03:15] <davechen1y> or, to put it another way
[03:15] <davechen1y> how can I change things so I get all notificatoins for all bugs on juju-core
[03:15] <thumper> I'm not sure...
[03:15] <thumper> you should have
[03:15] <thumper> sure you don't have some weird ass email rules?
[03:15] <davechen1y> i have no email rules
[03:15] <davechen1y> i hate thunderbird so much
[03:16] <davechen1y> i'm not going to give it the satisfactoin of asking it to take on more responsibility
[03:17] <davechen1y> ok, think I fixed it
[03:17] <davechen1y> i was sure the entire gophers team was subscribed
[04:40] <wallyworld_> thumper: do you have a copy of juju tools for precise compiled from tip you can share with me?
[04:42] <wallyworld_> actually, never mind, found some i think
[05:19] <arosales> wallyworld_: question for you if you are free
[05:19] <wallyworld_> sure
[05:26] <arosales> wallyworld_: are there any other package requirements for running go-juju other than juju-core?
[05:27] <arosales> I retract that question I was able to get AWS deployed, so I think I have the requirements meet
[05:27] <wallyworld_> \o/
[05:27] <arosales> hp still giving me some issues
[05:27] <wallyworld_> yeah, i found problems with jujud and other things, working on fixing now. sadly, hp cloud runs a different version to canonistack = problems
[05:29] <arosales> wallyworld_: any idea what this error means
[05:29] <arosales> 2013/02/27 23:29:06 JUJU juju bootstrap command failed: cannot find tools: no compatible tools found
[05:30] <wallyworld_> arosales:  you need to specify --upload-tools when using bootstrap as there is no well defined public bucket yet like for ec2
[05:30] <wallyworld_> so for now, when testing, we just upload our own copy
[05:31] <wallyworld_> there will ultimately need to be a public place where the tools tarball lives which everyone shares
[05:32] <arosales> wallyworld_: is there a test bucket I can use?
[05:33] <arosales> I am thinking I need to state something to the effect "juju --upload-tools <something> bootstrap -e hpcloud"
[05:33] <wallyworld_> not that has been setup. if you use --upload-tools, it just puts a copy in your control bucket, around 2Mb i think
[05:33] <wallyworld_> just "juju bootstrap --upload-tools -e hpcloud"
[05:34] <wallyworld_> if you specify a public bucket url in your yaml, it will use that
[05:34] <wallyworld_> but that implies the tools have been pre-uploaded separately
[05:34] <wallyworld_> which we will do at some point
[05:34] <wallyworld_> and publicise the public bucket url, like for ec2
[05:35] <wallyworld_> but for now, the above bootstrap command does the job
[05:35] <wallyworld_> bear in mind, bootstrap will fail for other reasons, currently being fixed
[05:35] <arosales> gotcha
[05:35] <arosales> interesting how this didn't parse
[05:36] <arosales> $ juju --debug --upload-tools bootstrap -e hpcloud
[05:36] <arosales> error: flag provided but not defined: --upload-tools
[05:36] <arosales> but you way did
[05:36] <wallyworld_> maybe that neds to go at the end
[05:36] <wallyworld_> ?
[05:36] <arosales> yup, worked when I did it your way, odd it parsed it correctly when at the end
[05:36] <wallyworld_> yeah, odd i agree
[05:36] <arosales> so it looks like I need have Go in my path?
[05:36] <arosales> error: cannot upload tools: build command "go" failed: exec: "go": executable file not found in $PATH;
[05:37] <wallyworld_> ah, you need the juju-core source and go to build the tools. hang on, i'll give you a url from which yo can download the tools tarball and upload manually to your hp cloudcontrol bucket
[05:38] <wallyworld_> you running precise or qantal?
[05:38] <arosales> quantal
[05:38] <wallyworld_> http://juju-dist.s3.amazonaws.com/tools/juju-1.9.9-precise-amd64.tgz
[05:38] <wallyworld_> sorry, subst quantal in there
[05:39] <wallyworld_> upload the tarball to a tools dir in your control bucket
[05:39] <arosales> in the gophers ppa I see "golang-stable" and "cobzr" do I need those?
[05:41] <wallyworld_> cobzr is for if you are doing devel work
[05:41] <wallyworld_> golang is Go itself
[05:47]  * arosales looking for hp cloudcontrol bucket   . . .
[05:48] <wallyworld_> arosales: i think i had to create mine manually, using the yaml control bucket vaue as the name
[05:48] <wallyworld_> if you tried bootstrap once, it may have made it for you already though
[05:49] <arosales> wallyworld_: I should see that in the object store for region 1, correct?
[05:49] <wallyworld_> depends on the region in your yaml but yes
[05:50] <wallyworld_> it is for me
[05:50] <arosales> ah yes, given I am trying to work in region 1
[05:51] <arosales> I don't see one there so sounds like I need to make one with the name in my env.yaml
[05:51] <wallyworld_> arosales: fyi, my control bucket is juju-e802cb1c2e3ab47e3e4a1071cef25a9c
[05:51] <wallyworld_> you may be able to see that one
[05:53] <wallyworld_> depending on your credentials
[05:55]  * arosales uploading . . .
[05:59] <arosales> hrm, still getting the cannot upload tools error
[05:59] <arosales> http://pastebin.ubuntu.com/5572611/
[06:01]  * wallyworld_ looks
[06:02] <wallyworld_> arosales: unless you have the dev stuff installed locally, you need to upload manually the tarball and bootstrap without the upload tools flag
[06:02] <wallyworld_> upload-tools is more of a dev option
[06:03] <arosales> ok, I uploaded manually so I'll drop the upload-tools option
[06:05] <arosales> wallyworld_: closer, but still not finding the tools
[06:05] <arosales> http://pastebin.ubuntu.com/5572619/
[06:06] <wallyworld_> arosales: you uploaded quantal tools right? check you yaml and see if there is a default-series value in there
[06:06] <wallyworld_> if it says precise, you need to comment it out
[06:07] <wallyworld_> you also need to change the image id to a quantal one
[06:07] <arosales> and I do have a object store container in az1 matching my control bucket in my env.yaml with juju-1.9.9-precise-amd64.tgz in it
[06:07] <wallyworld_> 75839 from memory
[06:07] <wallyworld_> oh, so you have uploaded a precise tarball?
[06:07] <wallyworld_> i thought you were running quantal?
[06:07] <arosales> I do have     default-series: precise in my env.yaml but my client is quantal
[06:07] <arosales> do they need to match
[06:07] <wallyworld_> no
[06:08] <wallyworld_> as long as default-series = tools tarball = image type you should be ok
[06:08] <arosales> correct I uploaded the precise tar file when I noticed my yaml had the default series for precise
[06:09] <wallyworld_> hmmm. not sure why it is complaining. did you upload tarbal to a tools container in the bucket?
[06:10] <arosales> ah I don't have it under a tools dir
[06:10] <wallyworld_> that would do it
[06:13] <arosales> wallyworld_: nice catch on the missing tools dir, my bad.  That does get me closer
[06:13] <arosales> http://pastebin.ubuntu.com/5572624/
[06:13] <arosales> looks like it has m1.small
[06:14] <arosales> I think for HP that needs to be standard.small, right?
[06:14] <wallyworld_> arosales: yeah, that has been changed, but may have missed the 1.9.9 release
[06:14] <wallyworld_> you now specify the flavour in the yaml
[06:15] <wallyworld_> using default-instance-type
[06:15] <arosales> via     default-instance-type: standard.small
[06:15] <arosales> ok
[06:15] <wallyworld_> but it may not be in the 1.9.9 release
[06:15] <wallyworld_> that is deprecated btw, until we get constrainst further progressed
[06:16] <arosales> seem it didn't like that yaml parameter
[06:16] <arosales> http://pastebin.ubuntu.com/5572629/
[06:16] <arosales> I can untar the precise yaml and correct
[06:17] <wallyworld_> arosales: the code to process it may not have made the 1.9.9 release
[06:17] <wallyworld_> so you might be out of luck until the next drop
[06:17] <arosales> ah there is just an executable in that tar file
[06:18] <wallyworld_> yes, jujud
[06:18] <arosales> ya looks to be that way
[06:18] <arosales> :-(
[06:18] <wallyworld_> sorry
[06:18] <arosales> so close but yet so far
[06:18] <wallyworld_> go juju works for ec2
[06:18] <arosales> we wanted to try some scale testing on HP
[06:18] <wallyworld_> close for openstack, but we only *just* finished the core code and are sorting out the final bits and oieces
[06:19] <wallyworld_> i'm really hopeful we'll be there for next release
[06:21] <arosales>  Looks like 1.9.10 is expected on march 9 if all goes well
[06:22] <arosales> wallyworld_: thanks for your time and help. I was going to write this up and send it out to folks wanting to deploy on HP cloud.  But I'll wait for that once the control tools are ready
[06:23] <arosales> wallyworld_: would you suggest I use the daily ppa?
[06:24] <wallyworld_> arosales: no problem, i'm just sorry we're not quite there yet. the daily ppa would have all the latest fixes in it (and maybe also bugs). but i can't be worse than now right
[06:24] <wallyworld_> s/i/it
[06:24] <wallyworld_> you still won't be able to get a system fully working though
[06:24] <wallyworld_> still some more things to sort out
[06:25] <arosales> ok, perhaps it is best to wait for 1.9.10 then
[06:25] <arosales> btw, do you have a pointer to the daily?
[06:25] <wallyworld_> not handy but i can find it
[06:29] <wallyworld_> arosales: https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily
[06:29] <wallyworld_> from there you can grab the one you want
[06:31] <arosales> wallyworld_: thanks for link, and thanks again for your time to help me step through the openstack setup for HP. Much appreciated
[06:31] <wallyworld_> no problem at all, please to help.
[06:31] <wallyworld_> hopefully next time we talk thiings will be working :-)
[06:32] <arosales> wallyworld_: do you want me to open up a bug on the control file needing updated to have standard.small?
[06:32] <wallyworld_> arosales: no, already fixed :-)
[06:32] <wallyworld_> just not in the release yet
[06:32] <arosales> ok
[06:33] <arosales> gotcha, enjoy the rest of your day.
[06:34] <wallyworld_> you too, almost wine o'clock here :-D
[06:39] <arosales> nice
[06:45] <arosales> I guess if I were to try the daily on HP I would need a matching control bucket tar file, which probably isn't available just yet . . .
[07:02] <wallyworld_> correct
[07:03] <wallyworld_> but you can get one from ec2
[07:03] <wallyworld_> no
[07:03] <wallyworld_> i don't think we upload the daily tarballs
[07:50] <arosales> yup, I didn't see one on ec2 with the urls I tried. have a good evening wallyworld_ ttyl
[08:11] <fwereade> morning gents
[08:12] <fwereade> I am reverting to r942, because r943 and all following were committed with failing tests
[08:12] <dimitern> fwereade: morning
[08:13] <fwereade> dimitern, heyhey
[08:13] <fwereade> dimitern, I has a grumpy: please run the full test suite before you submit
[08:13] <dimitern> fwereade: I saw that bug report about failing uniter tests
[08:13] <dimitern> fwereade: I *did* several times!
[08:13] <fwereade> dimitern, frankly, please run it before yu even propose
[08:13] <fwereade> dimitern, hm, that is odd then
[08:13] <dimitern> fwereade: I always do
[08:14] <dimitern> really odd
[08:14] <fwereade> dimitern, sadly they're failing consistently for me in r943, and ok in r942, so I'm backing everything out until we can figure out what went wrong
[08:15] <dimitern> fwereade: ok, I'll investigate what went wrong
[08:15] <rogpeppe> mornin' all
[08:15] <dimitern> rogpeppe: hiya
[08:15] <rogpeppe> fwereade: yeah, i get a compilation failure in trunk
[08:16] <fwereade> rogpeppe, a *compilation* failure? goose maybe?
[08:16] <dimitern> rogpeppe: where?
[08:16] <rogpeppe> fwereade, dimitern: it's pretty weird actually:
[08:16] <rogpeppe> state/assign_test.go:5: cannot use &txn.Op literal (type *txn.Op) as type txn.Op in return argument
[08:17] <rogpeppe> but that's on an import statement
[08:17] <dimitern> rogpeppe: hmm
[08:17] <rogpeppe> i'll blow away $GOPATH/pkg and see if it still happens
[08:17] <fwereade> rogpeppe, huh, I didn't see that myself :/
[08:17] <dimitern> rogpeppe: what did you run?
[08:17] <rogpeppe> dimitern: go test ./...
[08:17] <rogpeppe> dimitern: in juju-core root
[08:17] <fwereade> dimitern, rogpeppe: for form's sake, can I get a quick check of https://codereview.appspot.com/7422044
[08:18] <dimitern> fwereade: I run go test -i ./... && go test ./... in worker/uniter several times when I was changing the uniter tests (to compare timings) - all was fine
[08:18] <dimitern> fwereade: I'm on it
[08:19] <fwereade> dimitern, you didn't change the uniter tests in r943 -- that was the SetCharm branch
[08:19] <dimitern> fwereade: hmm
[08:20] <dimitern> fwereade: well, yes I confess i didn't run the uniter tests when I did setcharm stuff, because it was only in state/ and all tests there run fine
[08:21] <fwereade> dimitern, IMO we should *always* be running the full test suite before we commit (really, before we propose)
[08:21] <rogpeppe> fwereade: +1
[08:22] <dimitern> fwereade: go test ./... in juju-core/ you mean?
[08:22] <fwereade> dimitern, we changed behavior in state -- anything that uses state *might* have been depending on something we changed
[08:22] <fwereade> dimitern, yeah
[08:22] <rogpeppe> fwereade: we should probably be running the live tests actually.
[08:22] <dimitern> fwereade: ok, sorry, I promise I'll do that from now on
[08:22] <fwereade> dimitern, thanks :)
[08:23] <fwereade> rogpeppe, hmm, what's the point of the double then?
[08:23] <dimitern> fwereade: i guess all my changes before were isolated enough so running the tests for what I changed was good enough
[08:23] <fwereade> rogpeppe, if the double can't tell us when we've broken things I question its value
[08:23] <rogpeppe> fwereade: it means that you get *some* confidence. but it doesn't run all the agents.
[08:23] <fwereade> dimitern, it's a tempting idea, but it has a tendency to bite one in the ass ;)
[08:24] <dimitern> rogpeppe: I have this failure in rpc: http://paste.ubuntu.com/5572797/
[08:24] <rogpeppe> dimitern: can you reproduce it (it works ok for me)
[08:24] <rogpeppe> ?
[08:25] <dimitern> rogpeppe: I just ran all tests (still running)
[08:25] <rogpeppe> fwereade: that compilation failure only happens against go tip. something weird's up.
[08:26] <rogpeppe> fwereade: i suspect a inlining bug
[08:26] <fwereade> rogpeppe, grar
[08:26] <rogpeppe> fwereade: i have an idea where it might lurk actually.
[08:28] <dimitern> fwereade: instead of reverting everything, can't we just revert my setcharm stuff?
[08:29] <dimitern> rogpeppe: running all tests again rpc was a PASS
[08:29] <rogpeppe> dimitern: hmm, i'll have a look at it
[08:29] <rogpeppe> some days, everything seems broken
[08:29] <dimitern> but this time I have a build failure in store
[08:29] <dimitern> # launchpad.net/juju-core/store
[08:29] <dimitern> store/lpad.go:7: import /home/dimitern/work/go/pkg/linux_amd64/launchpad.net/lpad.a: not a package file
[08:29] <rogpeppe> dimitern: that does seem weird
[08:30] <rogpeppe> dimitern: it might be because you interrupted a compilation in an odd place, i suppose
[08:30] <rogpeppe> dimitern: try blowing away that file and trying again
[08:32] <dimitern> rogpeppe: that solved it
[08:33] <dimitern> fwereade: before you revert all that, let me just check if reverting the setcharm cl will solve the issues
[08:33] <rogpeppe> hmm, i think i've found where my compilation error comes from: 	func (@"".s·2 <EMAIL_ADDRESS>"esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return<EMAIL_ADDRESS>C:@"".s·2<EMAIL_ADDRESS>Id<EMAIL_ADDRESS><EMAIL_ADDRESS>0x0:{ Name:"txn-revno", Value<EMAIL_ADDRESS>} }) } }
[08:33] <rogpeppe> there's a spurious & in there
[08:33] <dimitern> rogpeppe: that seems like the same cl
[08:33] <dimitern> rogpeppe: my bad again :(
[08:33] <rogpeppe> dimitern: the code looks fine though
[08:35] <fwereade> dimitern, I kinda want to roll back to before that point
[08:36] <fwereade> dimitern, I don't know wtf tim/ian/gustavo were doing committing their changes without running the test suite
[08:36] <dimitern> fwereade: and after that we selectively reapply each CL to see were it failed?
[08:37] <fwereade> dimitern, after that it's up to RUN THE TESTS and then maybe resumbit their code
[08:38] <fwereade> dimitern, I am not exclusively grumpy with you, I am grumpy with everyone who committed to a broken trunk without reverting it
[08:39] <dimitern> fwereade: fair enough, although I don't think it's fair for other people to suffer if i'm the one to blame (probably)
[08:40] <fwereade> dimitern, you're the ultimate cause of the failures, but they're responsible for running the tests as well -- if something like this slips through again (which it will, someone will make some series-specific assumption) it should be the detector's responsibility to unbreak, notify the perpetrator, and submit on top of a *clean* trunk
[08:41] <dimitern> fwereade: yes, you're right - they should've run the tests before landing after it was broken
[08:42] <dimitern> fwereade: it might be even a good thing to put in the channel topic: RUN juju-core/$ go test ./... BEFORE EVEN PROPOSING A CHANGE :)
[08:49] <dimitern> fwereade: hmm, it seems maybe I'm not the only one to blame, because reverting the setcharm CL and running the tests they failed in state/watcher/
[08:49] <rogpeppe> fwereade: FWIW proposing does a merge, so really you should merge trunk, *then* test everything
[08:49] <fwereade> rogpeppe, what, people aren't already doing this?
[08:50] <fwereade> rogpeppe, I guess not
[08:50] <rogpeppe> fwereade: not necessarily before very propose. the problem is it can muddy the diffs
[08:50] <rogpeppe> s/very/every
[08:50] <fwereade> rogpeppe, if the diffs are muddied it's because the change to trunk has actually muddied the proposal
[08:50] <dimitern> fwereade: I merge trunk before proposing ever since I had issues with MPs in LP with MAAS
[08:51] <fwereade> dimitern, +1
[08:51] <rogpeppe> fwereade: i always merge before submitting, but not always before every re-propose
[08:52] <rogpeppe> fwereade: otherwise you see big diffs between the different revisions in codereview, so people can't easily see what you've changed in response to their review
[08:52] <fwereade> rogpeppe, first propose and final sumbit are the points at which I think there's no excuse
[08:52] <dimitern> after reverting 943 I have this failure:
[08:53] <dimitern> FAIL: watcher_test.go:285: WatcherSuite.TestDoubleUpdate
[08:53] <dimitern> watcher_test.go:295:
[08:53] <dimitern>     assertNoChange(c, s.ch)
[08:53] <dimitern> watcher_test.go:82:
[08:53] <dimitern>     c.Fatalf("watch reported %v, want nothing", got)
[08:53] <dimitern> ... Error: watch reported {test a 4}, want nothing
[08:53] <fwereade> rogpeppe, being a bit casual about midstream proposes is probably ok :)
[08:53] <dimitern> all others pass
[08:54] <fwereade> dimitern, would you have a quick look in the juju-core bugs? I suspect that is known but intermittent and rare enough that we haven't managed to track it down yet
[08:54] <dimitern> fwereade: looking
[08:55] <dimitern> fwereade: I cannot find anything similar, I'll file a bug
[08:58] <fwereade> TheMue, https://bugs.launchpad.net/juju-core/+bug/1135442
[08:58] <_mup_> Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >
[08:59] <dimitern> there it is bug 1135444
[08:59] <_mup_> Bug #1135444: state/watcher intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135444 >
[09:00] <fwereade> TheRealMue, https://bugs.launchpad.net/juju-core/+bug/1135442
[09:00] <_mup_> Bug #1135442: local storage test intermittent failure <juju-core:New for themue> < https://launchpad.net/bugs/1135442 >
[09:01] <fwereade> dimitern, rogpeppe, TheRealMue: I'm about to submit https://codereview.appspot.com/7422044
[09:01] <rogpeppe> fwereade: how much history does it unwind?
[09:01] <dimitern> fwereade: go for it
[09:01] <fwereade> rogpeppe, about 5 revs
[09:02] <rogpeppe> fwereade: i was wondering if it might be better just to unwind dimiter's change
[09:02] <fwereade> rogpeppe, tim, gustavo and ian *all* committed with broken code
[09:02] <rogpeppe> fwereade: but was it their code that was broken, or just the one merge that they committed on top of?
[09:03] <fwereade> rogpeppe, if trunk is broken and you commit to it, you broke trunk too
[09:04] <rogpeppe> fwereade: i guess so
[09:04] <dimitern> there is the other rpc bug 1135452
[09:04] <_mup_> Bug #1135452: rpc: intermittent test failure <juju-core:New> < https://launchpad.net/bugs/1135452 >
[09:06] <fwereade_> rogpeppe, am I insane? I know I am pissed off but I *think* my judgment is clear here
[09:07] <fwereade_> rogpeppe, if the tests don't pass, it's not ok to commit
[09:07] <rogpeppe> fwereade_: i'd probably just unwind the commit that causes the problem, but i know that's more hassle
[09:07] <fwereade_> rogpeppe, if someone else broke it, you don't get to say "meh, not my problem" and compound the issue
[09:07] <dimitern> fwereade_: +1
[09:09]  * fwereade_ submits
[09:18] <dimitern> now on to making things right again :)
[09:20] <fwereade> dimitern, cheers :)
[09:26] <TheMue> fwereade: Oh, thx, will investigate. Have missed your notification.
[09:27] <fwereade> TheMue, I think you just need to let the system pick the port for each test
[09:27] <TheMue> fwereade: Yep, no constant value.
[09:29] <TheMue> fwereade: To avoid the current troubles which rev shall I take? 942?
[09:29] <fwereade> TheMue, I've reverted everything since r942 so yu should be good to go with tip
[09:29] <TheMue> fwereade: OK, will do so.
[09:33] <fwereade> rogpeppe, a thought re running live tests
[09:33] <fwereade> rogpeppe, we do at least have tests for the userdata we send up with a new instance, right?
[09:33] <rogpeppe> fwereade: well, some basic sanity checking, yeah.
[09:34] <rogpeppe> fwereade: but it doesn't actually run anything
[09:34] <fwereade> rogpeppe, if those checks are not sufficient to guarantee that the userdata still works, I don't think that's enough
[09:34] <fwereade> rogpeppe, I understand we don't want to run things
[09:35] <fwereade> rogpeppe, but is it not possible to figure out which bits can change (and how) and which bits can't?
[09:35] <rogpeppe> fwereade: in the end, how can you test it properly without actually running it on the target machine?
[09:36] <fwereade> rogpeppe, well, how much actually changes in the userdata from one machine to another?
[09:36] <fwereade> rogpeppe, AIUI the bulk of it is identical; the bits that change surely do so in a predictable way, right?
[09:36] <rogpeppe> fwereade: it's not the user data, it's the environment that the user data runs in. the *combination* needs to be tested, no?
[09:37] <rogpeppe> fwereade: i'm not quite sure where you're going here
[09:38] <fwereade> rogpeppe, I'm saying that if the userdata changes in a way we don't have good reason to believe to be sane, tests should fail
[09:39] <rogpeppe> fwereade: i'm not quite sure what kind of check you're thinking of here.
[09:39] <rogpeppe> fwereade: and if it such a check would actually have caught any of the actual failures we've seen in the past
[09:42] <fwereade> rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/
[09:43] <fwereade> rogpeppe, do you consider this to be adequate?
[09:51] <fwereade> rogpeppe, if yu said anything, I didn't see it
[09:52] <rogpeppe> fwereade: i didn't - sorry, i didn't see your reply earlier.
[09:52] <rogpeppe> fwereade: those tests should certainly be better
[09:52] <fwereade> rogpeppe, I haven't seen anything since:
[09:52] <fwereade>  <fwereade> rogpeppe, it appears that the only testing we actually have is as follows: http://paste.ubuntu.com/5572927/
[09:52] <fwereade>  rogpeppe, do you consider this to be adequate?
[09:52] <rogpeppe> fwereade: i haven't said anything since then
[09:53] <fwereade> rogpeppe, ok, cool, just wondered if stuff got stuck
[09:53] <fwereade> rogpeppe, o you see my point, though? that we could do *much* better here
[09:54] <fwereade> rogpeppe, and that the local tests ought if anything to be an over-sensitive canary for the live tests
[09:54] <rogpeppe> fwereade: i'm sure that's true. however, would better tests there have caught any of the problems we've actually seen?
[09:54] <fwereade> rogpeppe, they should fail so people know to run the live tests for verification
[09:54] <fwereade> rogpeppe, are yu telling me that you have never written code which passes the local test suite but doesn't work in reality?
[09:55] <rogpeppe> fwereade: i'm saying that the reason it failed would not have been caught by a simple script test.
[09:55] <rogpeppe> fwereade: the important script tests are in cloudinit, which *does* check the scripts in detail.
[09:56] <rogpeppe> fwereade: the idea of the tests in the individual providers is that they check that the right params were passed to cloudinit. they should definitely do better in that respect
[09:57] <fwereade> rogpeppe, so you've written code that broke juju without changing the scripts... but have never written code that changed the scripts that didn't break juju?
[09:57] <fwereade> rogpeppe, even if that is the case I don't think we can assume that everyone has so complete an internal ubuntu simulator
[09:57] <rogpeppe> fwereade: when i wrote code that changed the scripts, the only way to tell if it will break juju is by running them live.
[09:58] <fwereade> rogpeppe, how do you know when you write code that changed the scripts?
[09:58] <rogpeppe> fwereade: when changing the actual scripts generation in cloudinit
[09:58] <fwereade> rogpeppe, that's not the only time
[09:59] <rogpeppe> fwereade: the other way is by changing the parameters in MachineConfig
[09:59] <fwereade> rogpeppe, or changing config.Config
[09:59] <fwereade> rogpeppe, or changing upstart, or cloudinit, or agent, or...
[10:00] <rogpeppe> fwereade: all of those are tested by the environs/cloudinit tests, no?
[10:00] <fwereade> rogpeppe, some of them may be
[10:00] <rogpeppe> fwereade: which should test for the range of possible MachineConfig configurations
[10:01] <fwereade> rogpeppe, is it not the case that individual providers construct their own MachineConfigs from scratch?
[10:01] <fwereade> rogpeppe, and that any one of the could, say, forget to strip secrets?
[10:03] <rogpeppe> fwereade: yup. i think perhaps the check in the provider should be check(userData, Equals, expectedMachineConfig.Render())
[10:03] <fwereade> rogpeppe, that sounds reasonable, I think, it closes the loop quite neatly
[10:04] <rogpeppe> fwereade: that *still* won't find out real world problems though. we'd still need to run live tests before submitting, really.
[10:05] <TheMue> fwereade: Got my fix done, but I've got 3 fails testing all. See http://paste.ubuntu.com/5572965/.
[10:05] <fwereade> rogpeppe, although I think it would probably be even better if you did a MachineConfig-style output check on the stuff passed up to the instance though
[10:05] <fwereade> rogpeppe, that way the test that fails will be at least close to the tests you need to run for verification
[10:06] <rogpeppe> fwereade: you mean have the scripts literally in each provider?
[10:06] <fwereade> TheMue, would you please: (1) verify they're intermittent (2) add bugs, mark them high (3) assign to likely people?
[10:06] <fwereade> TheMue, I can take the filter test
[10:07] <TheMue> fwereade: Will do so, yep.
[10:07] <fwereade> TheMue, I suspect ian is a good candidate for TestPersistence in openstack
[10:07] <TheMue> fwereade: OK
[10:07] <fwereade> rogpeppe, is OpPutFile is your stuff?
[10:08] <rogpeppe> fwereade: it was originally, though it's changed a bit since i last touched it i think.
[10:08]  * TheMue has to do a short break, bringing daughter to work. BIAB
[10:08] <fwereade> rogpeppe, yeah, I think so
[10:08] <rogpeppe> fwereade: it's enough of a pain changing the literal scripts inside cloudinit that i'm not sure doing it in many other places is a great idea.
[10:09] <fwereade> rogpeppe, surely it is dwarfed by the effort of running each set of live tests?
[10:10] <rogpeppe> fwereade: i'm not sure how it helps particularly. rather than check(userData, Equals, expectedMachineConfig.Render()), we've got check(userData Equals, someLiteralStringWhichWeNeedToChangeEveryTimeCloudinitChanges)
[10:11] <rogpeppe> fwereade: if there's a bug in the generated scripts, it's in environs/cloudinit, not the providers themselves.
[10:12] <fwereade> rogpeppe, nonsense
[10:12] <rogpeppe> fwereade: assuming that the correct args are passed into MachineConfig
[10:12] <fwereade> rogpeppe, the environs create the input data
[10:12] <rogpeppe> fwereade: (which is checked by the suggested userdata test)
[10:13] <rogpeppe> fwereade: surely it's cloudinit's job to turn the MachineConfig spec into an actual script? the important thing in each provider is not the exact form of the script but the spec that's passed to cloudinit AFAICS.
[10:15] <rogpeppe> fwereade: if we find that cloudinit is generating the wrong script given some set of input params, we should add that set of input params to the cloudinit script tests.
[10:16] <fwereade> rogpeppe, we should, yes; but we should also have some reason to believe that those scripts will run live
[10:16] <fwereade> rogpeppe, the number of things that change the cloudinit output is potentially high
[10:17] <fwereade> rogpeppe, if someone causes a change there, they should be running those actual changes live
[10:17] <fwereade> rogpeppe, ...shouldn't they?
[10:19] <rogpeppe> fwereade: any time the cloudinit tests need adjusting, we should run all live tests. in fact, anytime *anything* changes, we should run all live tests. the scripts are a very minor part of it.
[10:23] <fwereade> rogpeppe, I agree that live tests should run regularly, but I don't think it's sane to impose that requirement in all cases... how long do the live tests take?
[10:24] <rogpeppe> fwereade: about 17 minutes currently
[10:24] <rogpeppe> fwereade: i do kinda see the point though - having the literal string as a "if it's different from this, you need to run the live tests".
[10:24] <fwereade> rogpeppe, ok, could have sworn it was longer :)
[10:24] <rogpeppe> fwereade: we could even use a hash of the output
[10:25] <rogpeppe> fwereade: it feels like it takes forever :-)
[10:25] <fwereade> rogpeppe, I think we need to be a bit smarter -- eg server certs/keys will change each time -- but in that case I'd check validity wrt the CA cert and leave it at that
[10:25] <rogpeppe> fwereade: it would mean that noone could submit any branch that changed the cloudinit output without it first being checked live against all providers
[10:26] <rogpeppe> fwereade: it's not that easy
[10:26] <fwereade> rogpeppe, hmm, go on?
[10:27] <fwereade> rogpeppe, my position is predicated on the idea that the few bits of the scripts that do change do so in predictable and checkable ways
[10:27] <rogpeppe> fwereade: if you want to check cloudinit output *without* the certs, you have to break up the cloudinit in exactly the same way that environs/cloudinit does. that's a frikking pain
[10:27] <fwereade> rogpeppe, nobody said good testing was easy
[10:28] <rogpeppe> fwereade: it's not just a pain, it's an *ongoing* pain.
[10:28] <rogpeppe> fwereade: because you need to search out the right bits to change every time the cloudinit output changes.
[10:29] <fwereade> rogpeppe, I think that's better than an ongoing situation in which "go test ./..." doesn't take a position on whether or not the providers actually work
[10:29] <rogpeppe> fwereade: this wouldn't either.
[10:30] <fwereade> rogpeppe, ISTM that it would fail any time there's a risk of the live tests failing
[10:30] <rogpeppe> fwereade: there's always a risk of the live tests failing
[10:30] <fwereade> rogpeppe, ...and it being a direct result of changes just made
[10:31] <rogpeppe> fwereade: can you give an example of a live test failure that this would have caught?
[10:32] <yolanda> hi, i'm having a problem creating juju instances in openstack, i have to run /var/lib/cloud/instance/scripts/runcmd on each machine to make it work
[10:33] <rogpeppe> fwereade: if we made the testing certs unchangable, things would be easier perhaps.
[10:33] <fwereade> rogpeppe, let me turn that around: if secrets are in the environ config, a test should fail. if the state server certs does not match the key, or cannot be verified by the ca cert, a test should fail. if the machine agent is not invoked with the correct machine id, a test should fail
[10:34] <fwereade> rogpeppe, the fact that we happen not to have broken any of these yet, as far as I am aware, does not impact the fact that they should actually be tested
[10:35] <rogpeppe> fwereade: all those things sound like tests on the MachineConfig input itself rather than than on the generated script.
[10:36] <rogpeppe> fwereade: perhaps there's a case for intercepting the render step to see what actually gets passed to cloudinit rather than trying the reverse-engineer the output
[10:39] <fwereade> rogpeppe, if use of cloudinit is optional in the providers -- which it is -- I think we must resign ourselves to checking what the providers actually produce
[10:40] <rogpeppe> fwereade: surely each provider can decide how best to check its user data? this is very much a provider-specific test.
[10:41] <mgz> optional in what sense?
[10:41] <fwereade> mgz, in the sense that we don't necessarily have cloudinit available
[10:41] <mgz> that's... not the case?
[10:42] <fwereade> mgz, maybe it's working in lxc now? it certainly wasn't a while ago
[10:42] <mgz> nothing functions at all unless cloudinit is present and runs
[10:42] <mgz> ah, lxc is special, and doesn't exist for go yet
[10:43] <rogpeppe> mgz: it will soon :-)
[10:44] <fwereade> mgz, anyway, rogpeppe just blocked a change of mine on the basis that cloudinit wasn't special
[10:44] <mgz> just using cloudinit for lxc too is probably simpliest
[10:44] <fwereade> mgz, he's right about this, I think
[10:45] <rogpeppe> mgz: at some point in the future we'll probably want juju to work under other systems without cloudinit (windows, for example)
[10:45] <fwereade> mgz, it would be a bit weird to explicitly pass cloudinit-specific stuff into an environ when launching an instance
[10:45] <mgz> I'm not sure about that.
[10:45] <mgz> I have two thoughts: we have too much junk in the cloudconfig that shouldn't really be there right now
[10:46] <fwereade> mgz, +1 on that, I think
[10:46] <mgz> but the generic stuff we'd just end up duplicating in something that looked very much like cloudinit if we didn't use it in a provider
[10:46] <rogpeppe> mgz: +1 too (i'd be interested to know which bits you're thinking of particularly though)
[10:47] <fwereade> mgz, this is why I'm so pissed off by MachineConfig in the first place
[10:48] <fwereade> mgz, it takes all the totally generic scripts-we-must-run stuff and smooshes it into a cloudinit-specific form
[10:48] <rogpeppe> fwereade: those scripts are generic enough to run under Windows? :-)
[10:49] <mgz> well, what do we mean by windows?
[10:49] <fwereade> rogpeppe, at the moment we can't run the version of ubuntu we wanr
[10:49] <mgz> we're a long, long way away from being able to use windows as a machine type in juju
[10:49] <mgz> but that's not what we're talkinga about with azure
[10:49] <rogpeppe> mgz: i though people were talking about "juju deploy activedirectory" as a possibility at some point
[10:50] <mgz> for azure, we basically don't control boot, but can get our ubuntu machine, then access it and do stuff, which can still be cloudinit
[10:50] <rogpeppe> s/though/thought/
[10:51] <mgz> I think "some point" should be clarified to not worrying about with detail design like this right now, it would entail changing... a great deal more than just this
[10:52] <mgz> fwereade: what's your branch, so I can catch up on the earlier discussion in the mp?
[10:53] <fwereade> mgz, it's just a sketch, up at https://codereview.appspot.com/7396055/
[10:53] <fwereade> mgz, sadly the discussion happened live
[10:53] <mgz> live here, or live hangout? :)
[10:53] <fwereade> mgz, hangout, I'm afraid
[10:53] <mgz> ah well, add to the list for next week :)
[10:55] <fwereade> mgz, as someone who came to the environs package cold, though, I would be very interested on your thoughts on that change
[10:55] <rogpeppe> fwereade: i don't think that was the CL i had an issue with
[10:56] <mgz> hm, "error: old chunk mismatch"
[10:56] <fwereade> rogpeppe, crap, you're right
[10:56] <fwereade> mgz, sorry, I have too many recent branches :/
[10:56]  * fwereade goes digging
[10:56] <rogpeppe> mgz: yeah, that happens. you can see the diffs though.
[10:56] <rogpeppe> mgz: it'll be fixed if fwereade re-proposes
[10:56] <mgz> launchpad will save me
[10:57] <fwereade> mgz, https://codereview.appspot.com/7394048/ -- and it does have some discussion
[10:57] <rogpeppe> mgz: https://codereview.appspot.com/7396055/patch/1/6
[10:57] <fwereade> mgz, it is just a sketch, only proposed -wip
[10:58] <mgz> ta
[11:00] <rogpeppe> mgz: the thrust of my argument AFAIR was that factoring out this stuff was a good idea, but i think it would be better to take place under the umbrella of Bootstrap, rather than adding lots of cloudinit-related stuff to the environs.Environ interface.
[11:01]  * rogpeppe goes back to trying to find that compiler bug
[11:02] <davecheney> rogpeppe: is this in 1.0.3 or tip ?
[11:02] <rogpeppe> davecheney: tip
[11:02] <davecheney> rogpeppe: already reported
[11:02] <rogpeppe> davecheney: have you narrowed it down?
[11:02] <davecheney> https://code.google.com/p/go/issues/detail?id=4932
[11:02] <davecheney> https://code.google.com/p/go/source/detail?r=e73800eb2b00
[11:02] <davecheney> stay below this revision for the moment
[11:03] <davecheney> or use hg revert
[11:03] <davecheney> i'm setting up a jenkins build against tip to ensure we catch this faster
[11:03] <davecheney> sorry, hg undo
[11:03] <rogpeppe> davecheney: ah, cool. i was trying to reproduce by trial and error.
[11:04] <rogpeppe> davecheney: i'd found this:
[11:04] <rogpeppe> func (@"".s·2 <EMAIL_ADDRESS>"esc:0x0") @"".assertUnchangedOp () (? @"labix.org/v2/mgo/txn".Op) { return<EMAIL_ADDRESS>C:@"".s·2<EMAIL_ADDRESS>Id<EMAIL_ADDRESS><EMAIL_ADDRESS>0x0:{ Name:"txn-revno", Value<EMAIL_ADDRESS>} }) } }
[11:04] <rogpeppe> davecheney: but couldn't reliably reproduce it in a small program
[11:04] <davecheney> rogpeppe: ironically, the fix was for an issue which was almost identical https://code.google.com/p/go/issues/detail?id=4879
[11:05] <davecheney> rogpeppe: nah, we use almost every conceivable style and permutation allowed by the language
[11:05] <rogpeppe> davecheney: i narrowed it down quite a bit
[11:05] <davecheney> try https://codereview.appspot.com/7437043
[11:07] <davecheney> ok, jenkins biuld is setup
[11:07] <davecheney> but is currently passing because r943 was rolled back
[11:08] <rogpeppe> davecheney: trying that CL
[11:08] <rogpeppe> davecheney: it sounds like they'd still benefit from a small test case
[11:09] <davecheney> yeah, i agree, have a look at the 4879
[11:09] <davecheney> the test case for that might be some of the way there
[11:10] <rogpeppe> davecheney: that CL fixed the problem
[11:13] <davecheney> rogpeppe: a test case would be useful
[11:13] <davecheney> Dmorsing was saying that the way composite literals work, stretches the meaning of work
[11:13] <rogpeppe> davecheney: how so?
[11:14] <davecheney> 20:21 < DMorsing> davecheney, the biggest problem is that the compiler does a lot of work on the ast
[11:14] <davecheney> 20:21 -!- fzzbt<EMAIL_ADDRESS>has quit [Client Quit]
[11:14] <davecheney> 20:22 -!- AnybodyElse<EMAIL_ADDRESS>has joined #go-nuts
[11:14] <davecheney> 20:22 -!- fzzy<EMAIL_ADDRESS>has joined #go-nuts
[11:14] <davecheney> 20:22 -!- gsamat<EMAIL_ADDRESS>has quit [Quit: Computer has gone to sleep.]
[11:14] <davecheney> 20:22 < DMorsing> and that either messes up later passes, or it messes up inlining because there isn't a proper representation of the post-processing AST
[11:17] <fwereade> davecheney, tyvm
[11:17] <davecheney> no worries
[11:18] <davecheney> i've got a build setup now that watches juju tip and go tip for breakages
[11:21] <davecheney> note: i am not running the tests (yet), just checking it compiles
[11:32] <jam> mgz: poke
[11:37] <mgz> jam, a, hey
[11:37] <jam> mgz: care to join us for mmubemboeumob ?
[11:39] <mgz> too many things going on, have fled to the conservatory
[11:53] <wallyworld_> ian@wallyworld:~/.hpopenstack$ juju deploy mysql
[11:53] <wallyworld_> error: cannot get latest charm revision: charm info errors for "cs:quantal/mysql": entry not found
[12:04] <rogpeppe> fwereade: have you looked at tim's latest CL? i'm not sure what i think - i'm interested in your reaction. https://codereview.appspot.com/7375053
[12:12] <fwereade> rogpeppe, looking
[12:23] <dimitern> fwereade: done with standup, shall we g+?
[12:24] <fwereade> dimitern, ok, would you start one please?
[12:24] <dimitern> fwereade: https://plus.google.com/hangouts/_/5fb9c8fa96a6d9bc74de7a5f5cf171a04aeb0a40?authuser=0&hl=en
[12:52] <jam> mgz, wallyworld_: https://code.launchpad.net/~jameinel/juju-core/only-943/+merge/151005
[12:56] <wallyworld_> jam: my rev's changes look like they're all there. thanks for doing that
[12:56] <jam> wallyworld_: np, if you can merge it and run the test suite quickly, it would help
[13:01] <wallyworld_> jam: hmmm. a failure, haven't looked yet.... PANIC: local_test.go:132: localServerSuite.SetUpTest
[13:01] <jam> wallyworld_: is it related to not enough bytes ?
[13:01] <wallyworld_> not sure, looking now
[13:02] <jam> wallyworld_: if you get a chance to paste the full traceback, please do so.
[13:03] <wallyworld_> jam: https://pastebin.canonical.com/85834/
[13:03] <jam> wallyworld_: that is the failure I'm working on in goose
[13:03] <jam> interesting we've only seen it a couple times recently
[13:03] <wallyworld_> ah ok
[13:03] <jam> we must be using a lot more random data.
[13:03] <wallyworld_> i'll rerun
[13:05] <wallyworld_> jam: all good this time
[13:06] <fwereade> jam, tyvm for reapplying those changes, if it's all passing it LGTM
[13:06] <jam> fwereade: thanks
[13:07] <jam> I've confirmed they pass here and for wallyworld_
[13:07] <fwereade> jam, <3
[13:07] <fwereade> jam, btw, I have a vague recollection mramm was going to talk to you about tarmac for juju-core at one stage, but I never followed up on it
[13:08] <jam> fwereade: I actually have it set up as lp:~goose-bot/juju-core/trunk, but I wasn't sure how we wanted to actually coordinate the deployment.
[13:08] <jam> I wasn't going to push for it until I updated 'lbox submit --tarmac'
[13:09] <jam> (And it would currently be out of date)
[13:10] <dimitern> wallyworld_: I think such intermittent failures deserve a bug report
[13:10] <fwereade> dimitern, +1
[13:10] <jam> dimitern: I have a patch submitted that you've reviewed for it, which is waiting for roger to approve
[13:10] <jam> so yes, we could have a bug, but we do have a fix
[13:10] <dimitern> jam: ah, that's your fix? ok
[13:10] <dimitern> jam: I though it's a new random thing
[13:11] <jam> wallyworld_: https://codereview.appspot.com/7375059/ is the one where fwereade is removing instanceid from being stored.
[13:11] <jam> dimitern: the panic is because random isn't giving enough data, and we end up with a nil somewhere.
[13:11] <jam> the fix should prevent that.
[13:11] <fwereade> jam, what are your current priorities? is there anything we can downgrade in favour of getting reliable builds set up?
[13:12] <wallyworld_> jam: that's great. i'll look tomorrow
[13:12] <jam> fwereade: well next week is sprinting :).
[13:12] <jam> And it depends if you want to require lbox submit --tarmac, if you can live with the manual steps we do for goose, I can get it set up quite quickly.
[13:12] <jam> The only remaining stuff is policy stuff
[13:12] <jam> do we want trunk to be only accessible by the bot
[13:13] <jam> or should the bot just be in the group that can commit to it.
[13:15] <fwereade> jam, I'm pretty comfortable declaring anything with a pulse to be untrustworthy
[13:16] <fwereade> jam, it'd be a shame not to have submit --tarmac, but I guess the answer depends more on how many manual steps there are and how onerous they are
[13:17] <jam> fwereade: you need to copy the description in Launchpad to the commit message, and then mark the proposal approved.
[13:17] <jam> (tarmac uses Commit Message rather than description)
[13:18] <fwereade> jam, that feels like it could be pretty easily scriptable, right? so even if there's trouble getting it into lbox, we should still be able to reap the benefits
[13:18] <fwereade> jam, the other big thing IMO is that with tarmac, we could actually get away with running likley subsets of the tests
[13:20] <fwereade> jam, and *that* then means we could put the deps in the source tree and get repeatable builds
[13:22] <fwereade> jam, (nobody's thought of an alternative route to get that without dropping the go tools, right?)
[13:22]  * rogpeppe goes for some lunch
[13:23]  * fwereade pops out for 5 mins in the sun, then over to dimitern's place for state talks; see you all soon
[13:23] <TheMue> cu
[13:35] <benji___> There appears to be a sort-order test bug on trunk (http://paste.ubuntu.com/5573328/); is that something you guys want a bug filed for?
[13:35]  * benji snipps off his tail.
[13:36] <dimitern> benji: can you file a quick bug report about it please?
[13:37] <benji> dimitern: will do
[13:37] <dimitern> benji: today everything breaks it seems
[13:37] <benji> :)
[13:40] <benji> dimitern: https://bugs.launchpad.net/juju-core/+bug/1135757
[13:40] <_mup_> Bug #1135757: List order test bug in launchpad.net/juju-core/environs/openstack <juju-core:New> < https://launchpad.net/bugs/1135757 >
[13:40] <dimitern> benji: cheers!
[13:42] <dimitern> benji: yeah, it seems that's related to ian's list prefix change
[13:47] <dimitern> benji: strange, I'm not getting it on tip - are you sure you've updated goose before?
[13:48] <dimitern> fwereade is here now
[13:49] <benji> dimitern: nope, I have not, let me try that real quick
[14:20] <jam> dimitern: did you manage to countersign your objectives? HR is asking me to do the final signoff.
[14:21] <jam> dimitern: https://allhands.canonical.com/hra-space/portal/root/employee
[14:21] <dimitern> jam: oh, you wrote here - yes I did
[14:22] <jam> I know you did the submission, there is a countersign step that has to happen after mine.
[14:22] <jam> I'm guessing you did it, but I want to make sure before I tell them.
[14:22] <jam> dimitern: ^
[14:25] <dimitern> jam: I double checked - there's no more to do on that page, tell me if I missed something. I just selected I agree + submit
[14:25] <dimitern> benji: did you manage to get the test pass?\
[14:25] <jam> if there aren't any tasks, then I don't see anything to do either.
[14:27] <benji> dimitern: let me check the test run...
[14:27] <dimitern> jam: yeah, i had to go to the archives page to see the countersign task
[14:27] <benji> it worked!  I guess that's something I need to internaize.
[14:27]  * benji writes "go get -u when you see test failures" 100 times on the blackboard
[14:28] <benji> It would be really nice if there were dependency management in place so a human didn't have to do that sort of thing.
[14:28] <dimitern> benji: cheers! please update the bug
[14:30] <benji> dimitern: done
[14:41]  * rogpeppe is back
[14:51] <TheMue> rogpeppe: Do you know if we meet in 10 minutes? Or only this evening? I have to step out now to fetch my daughter. Today I'm the driver. ;)
[14:52] <rogpeppe> TheMue: i'm not sure. i *presume* only this evening. mramm?
[14:52] <niemeyer> Yo all!
[14:52] <niemeyer> mthaddon: ping
[14:52] <rogpeppe> niemeyer: hiya!
[14:52] <TheMue> niemeyer: Hi.
[14:52] <mthaddon> niemeyer: pings with content save time :)
[14:53] <niemeyer> mthaddon: https://portal.admin.canonical.com/59712
[14:53] <mthaddon> niemeyer: cool, thx, we'll get it done soon - is there a particular deadline for it, or just "sooner the better"?
[14:53] <niemeyer> mthaddon: I generally like to say "Hi, how's life been since we last deployed it?", but alright :)
[14:53] <mthaddon> heh
[14:53]  * TheMue is AFK, BIAB
[14:54] <niemeyer> mthaddon: There's no deadline, but sooner the better indeed
[14:54] <niemeyer> mthaddon: There's a new stats feature
[14:54] <niemeyer> mthaddon: Can't see that data while it doesn't land
[14:54] <mthaddon> niemeyer: ok, thx
[14:54] <niemeyer> rogpeppe, TheMue: Yos
[14:55] <mramm> rogpeppe: TheMue: yea, just the evening meeting is fine
[14:58] <mthaddon> niemeyer: the RT mentions revno 945 - is 949 okay (our scripts pull tip by default)?
[14:58] <niemeyer> mthaddon: Yeah, it's okay
[14:58] <mthaddon> thx
[14:59] <mthaddon> niemeyer: done
[15:00] <niemeyer> mthaddon: Sweet! Let me test it
[15:00] <niemeyer> mthaddon: WORKS!
[15:01] <mthaddon> good good
[15:01] <niemeyer> mthaddon: Thanks much
[15:01] <mthaddon> np
[15:04] <fwereade> mramm, TheMue, rogpeppe: kanban?
[15:04] <mramm> fwereade: we decided to only do the one this evening
[15:04] <fwereade> mramm, ah!
[15:05] <fwereade> mramm, good point
[15:05] <fwereade> mramm, ok then :)
[16:52] <fwereade> knocking off now, we've got the call later
[17:59] <niemeyer> fss: ping
[18:32] <bac> hi rogpeppe, would you time to do a second review for me?
[18:32] <rogpeppe> bac: sure
[18:32] <rogpeppe> bac: link?
[18:32] <bac> cool, i hope you're not EOD
[18:32] <bac> rogpeppe: https://codereview.appspot.com/7369058/
[18:32] <rogpeppe> bac: normally yes, but today i'm working later
[18:42] <rogpeppe> bac: reviewed
[18:53] <bac> rogpeppe: thank.  looking at it now
[20:09] <niemeyer> fss: pingous?
[21:02] <fss> niemeyer: hi
[21:02] <niemeyer> fss: Heya.. you've got reviews
[21:02] <niemeyer> fss: Great stuff.. just trivial comments
[21:03] <fss> niemeyer: I'm lbox proposing group changes right now :-)
[21:03] <niemeyer> fss: Sweet
[21:03] <fss> niemeyer: regarding the message returned by amazon, that's the message
[21:04] <fss> niemeyer: should I use %q anyway?
[21:06] <rogpeppe> right, i'm off for the night. see y'all tomorrow.
[21:21] <niemeyer> fss: Does it include quotes around the name or not?
[23:04] <jcastro> mramm: around?
[23:12] <mramm> jcastro: I am now
[23:16] <jcastro> got time for a quick G+?
[23:16] <jcastro> 2 minutes, I promise!
[23:16] <jcastro> mramm: https://plus.google.com/hangouts/_/097d689c217f97e00665bff91bac17fd9b78e439?authuser=0&hl=en
[23:55] <mramm> jcastro, sorry I missed you...
[23:58] <jcastro> no worries
[23:58] <jcastro> next time


[21:00] <wrst> afternoon chris4585
[21:56] <chris4585> hey wrst
[21:56] <wrst> chris4585: how you doing?
[21:56] <chris4585> good, you?
[22:38] <wrst> doing well looking at routers, have any suggestions?
[22:43] <chris4585> wrst, nope, I use the modem that comes from the cable company
[22:43] <chris4585> I'm not a router guy
[22:44] <wrst> well we have about 10-12 devices that connect
[22:44] <wrst> so its a necessity but don't like it
[22:52] <chris4585> yeah
[22:55] <wrst> haven't decided to go with a good home setup or go with a decent wired router with an access point
[22:57] <chris4585> well our modem has a 4 port built in router, so for my extra connections I have an old linksys switch I think
[23:15] <wrst> no WiFi?
[23:15] <chris4585> it has built in wifi
[23:15] <chris4585> modem + router + wifi
[23:15] <chris4585> all in one
[23:15] <chris4585> and phone..
[23:16] <chris4585> but who uses a land line these days?
[23:16] <chris4585> lol
[23:25] <RagnarokAngel> anyone here root their android w/ superoneclick?
[23:25] <wrst> yeah I know chris4585
[23:25] <wrst> hey RagnarokAngel  galaxy s iii here that wasn't available for it
[23:26] <RagnarokAngel> shortfuse.org seems to be down
[23:26] <RagnarokAngel> and I can't find the binaries elsewhere
[23:26] <wrst> I think I used ginger break or something on my old phone it was a one click kind of deal
[23:28] <RagnarokAngel> I just don't understand how the only website with official linux binaries is down.


[00:03] <teward> slangasek: thanks
[02:06] <nagromlt> no h yet for bt ?
[02:06] <nagromlt> on ##crypto and #bitcoin
[02:24] <nagromlt> no pussies
[05:58] <Logan> I can't seem to figure out why gem2deb isn't building: https://launchpad.net/ubuntu/+source/gem2deb/0.20.1
[05:58] <Logan> we have a new enough ruby-all-dev
[06:26] <ScottK> It's apparently uninstallable.
[06:27] <ScottK> Logan: the log won't tell you why. The easiest thing to do is to try and install it locally and see if it fails.  Keep a particular eye on trying to use packages from universe.
[06:28] <Logan> okay, thanks! the log doesn't make it very clear that ruby-all-dev is not installable :(
[06:28] <Logan> "not going to be installed" reads more like "I can't find it"
[06:39] <Logan> hmm, it installs fine locally
[06:39] <Logan> in fact, it's already installed on my box
[15:06] <Laney> siretart: hi, can we drop the -dev package from libav maybe?
[15:07] <Laney> package*s*
[16:10] <infinity> Laney: Any ideas about the general sketchiness of the udisks2 force-removal test?
[16:11] <infinity> Laney: Is that a bug in the test, or is the test correctly finding a bug in the code (or the system)?
[16:12] <Laney> infinity: Don't know, hoping pitti will save us all when he comes back
[16:12] <Laney> he's the udisks2 guy really
[16:12] <infinity> Hahaha.
[16:12] <Laney> I got as far as seeing "yup, that sure does hang locally"
[16:13] <infinity> Laney: I'm tempted to let glib2 through, since it *seems* mostly unrelated, though it's crazy suspicious and weird that the pass/fail flip-flopped after the glib upload.
[16:13] <infinity> (Used to fail on amd64, pass on i386, now it's the inverse, lolwut?)
[16:14] <Laney><EMAIL_ADDRESS>[16:14] <infinity> Laney: Yeah.  Ima leave proposed in its current state and let glib suffer for this one until we investigate more.
[16:15] <Laney> glib and a kernel in there
[16:16] <Laney> Might spend a few tomorrow running it interactively, but otherwise it'll be easier to wait, I bet. :)
[16:16] <infinity> Kernel's certainly equally likely.
[16:17] <infinity> Annoying, ci.debian.net only runs amd64, so that's not much use to compare against.
[16:21] <Laney> Haha.
[16:21] <Laney> It's skipped there anyway
[16:24] <infinity> Oh, breaks-testbed.  Indeed.
[16:24] <infinity> Wish the ci UI would call that something other than a "pass". :P


[12:41] <mdeslaur> Could someone take a look and help me figure out why this build is failing? https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/13101220
[14:20] <tseliot> mdeslaur: FAIL: input
[14:20] <tseliot> input: ../../test/input.c:1773: process_input_proc: Assertion `ev->any.type == ++last_evtype' failed.
[14:20] <mdeslaur> tseliot: yeah, what's up with that?
[14:21] <tseliot> mdeslaur: do you have access to test/test-suite.log ?
[14:21] <mdeslaur> I don't, no
[14:21] <mdeslaur> I'll have to find an armhf box
[14:21] <tseliot> yes, that would help
[14:33] <jcristau> tseliot: test-suite.log won't have anything more than the assertion message
[14:35] <jcristau> (the test log is included in the build log, as we pass VERBOSE=1 to make check)
[15:03] <tseliot> jcristau: good to know, thanks
[17:14] <mamarley> ricotz: Did you see my message yesterday about adding kernel patches for 340.102 in https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages ?
[20:25] <ricotz> mamarley, hi, hmm, I guess I missed it
[20:26] <ricotz> mamarley, nice, although precise and yakkety are EOL
[20:38] <ricotz> copied :)


[05:55] <Abhijit> Hi
[05:55] <Abhijit> where can get the latex class used for ubuntu manual project and use it? i guess it must be open sourced?


[00:00] <rmg51> from what I heard Septa is shutting down
[00:01] <rmg51> and schools are closed
[00:03] <rmg51> if this keeps up I'll have to stay home to baby sit Mom
[00:05] <ChinnoDog> I am ready to survive on peebs
[00:05] <ChinnoDog> I should run a load of dishes tonight while there is still power
[00:06] <ChinnoDog> Also instructed my ice maker in my freezer to fill the tray
[00:06] <rmg51> to put this laptop in hibernation or not
[00:06] <ChinnoDog> My office is officially closed now
[00:06] <ChinnoDog> hibernation vs suspend?
[00:06] <rmg51> yep
[00:07] <rmg51> if power goes out during the day and I'm at work, will the battery last long enough?
[00:07] <rmg51> most likely it will
[00:11] <ChinnoDog> Better to hibernate to get the maximum juice out
[00:14] <rmg51> I'll wait till morning to decide
[01:46] <waltman> pretty much everything's going to be closed in Philly until Wedneesday
[02:00] <rmg51> not my place
[02:00] <rmg51> it's always open
[02:01] <rmg51> my boss is to dumb to know when to stay closed
[02:01] <rmg51> there is always something to do
[02:02] <rmg51> like pump water out of the basement :P
[02:29] <waltman> Drexel's closed Monday and Tuesday
[02:29] <waltman> to be honest it doesn't seem very stormy here yet.
[02:47] <waltman> So one of the PhD students in my lab just sent out this email: "I have taken the servers down in preparation for the big storm.  They will not be back online until Wednesday at the earliest."
[02:47] <waltman> We only have one server that I know of, and it also runs our website. Which is now offline.
[03:11] <waltman> I don't understand the problem he's trying to solve by doing this.
[03:11] <waltman> I can think of two problems -- losing power and a flood in the computer room. The first should be handled by the UPS. In case of the latter, the box is dead anyway.
[03:26] <waltman> oh nice, the servers aren't on UPS.
[03:26] <waltman> still, linux generally doesn't corrupt data when it loses power.
[09:27] <rmg51> Morning
[09:49] <anduril> morning all
[10:24] <jedijf> roads are dead
[11:52] <waltman> JonathanD: So trips to Ghana and Copenhagen weren't enough? You also had to toss in a Giants World Series win? You're not pretending about pleia2's holodeck anymore, are you?
[11:53] <pleia2> he's letting me out after all this (I'll be in Philly next week)
[11:53] <waltman> I'm just worried that your basement's going to flood and she's going to wake up and find out that the Yankees really won the Series.
[11:54] <pleia2> :(
[11:54] <waltman> enjoy it while you can! :)
[11:54] <pleia2> hehe
[11:54] <pleia2> I kind of feel bad for the tigers
[11:54] <pleia2> just a little
[11:54] <pleia2> apparently the game last night was good though :)
[11:56] <waltman> I'd feel a bit more sympathy for Detroit fans if the Lions didn't beat the Eagles a few weeks ago. :)
[11:58] <waltman> So far it's just wet here.
[12:03] <JonathanD> :D
[12:50] <anduril> so whats this about the atlantic city board walk going away?
[14:16] <teddy-dbear> Hi peoples
[14:37] <ChinnoDog> "going away"?
[18:25] <ChinnoDog> Still not doing a whole lot out there
[18:27] <waltman> ChinnoDog: where are you?
[18:29] <ChinnoDog> Merrifield, VA
[18:31] <waltman> ah
[18:31] <waltman> I'm in the Philly burbs and it's just raining hard.
[18:38] <Sadin> I hope we lose power at work
[18:38] <Sadin> :)
[18:39] <Sadin> well kick all out customers out and lock the doors and sit under the emergency lights and still get paid :D
[18:39] <Sadin> mcdonalds logic, dont send anyone home, pay us for sitting in a dark in operational store
[20:23] <waltman> http://www.npr.org/blogs/thesalt/2012/10/29/163874835/sandwich-monday-the-pb-p # keep this in mind when you start running out of food
[20:42] <anduril> hmm play skyrim or borderlands 2 tonight
[20:44] <anduril> haha al roker is getting blown around like a fool
[20:51] <mikedep333> anduril, still happening
[20:51] <mikedep333> hi all
[20:52] <mikedep333> has anyone else viewed the new FEMA 2010-2011 draft flood maps?
[20:52] <mikedep333> it uses google earth
[23:55] <rmg51> power just came back on
[23:56] <waltman> how long was it out?
[23:57] <rmg51> went out around 4:22


[08:35] <dholbach> good morning
[08:47] <davidcalle> Morning o/
[08:53] <dholbach> salut davidcalle
[09:11] <czajkowski> Aloha
[09:11] <nigelb> czajkowski: Congrats on CC elections :)
[09:14] <czajkowski> nigelb: THank you
[09:14] <czajkowski> looking forward to working with more great people in our community
[09:15] <nigelb> :)
[10:14]  * dholbach relocates to the office, brb
[11:34] <dholbach> davidcalle, are we still waiting on IS for a db udpate on staging?
[11:41] <davidcalle> dholbach, we are, in the meantime I'm testing what I can :)
[11:42] <dholbach> it will be interesting to see how it works with live data :)
[16:09] <balloons> popey, jose, happy monday to you. Shall we have a quick HO today / tomorrow to talk GCI?
[16:10] <jose> balloons, popey: tomorrow 14 UTC sounds good to you?
[16:13] <balloons> tomorrow morning is pretty full for me; I'd guess popey as well actually. Is there a time later today?
[16:26] <balloons> jose, ^^
[16:36] <jose> hmm, later today is popey gonna be available?
[16:45] <popey> depends on the time, I have loads of family stuff on a monday night
[16:45] <popey> but ping me, and I'll be there if I can
[16:50] <balloons> ok, well, I really just wanted to discuss the last big push for tasks. As you know, we need to get to at least 75, and should have alot more. It's time to follow-up with all the mentors and make sure they have things in the tool
[16:52] <dholbach> all rightie... I call it a day - see you all tomorrow!


[00:51] <kdub> wat up channel
[01:46] <pleia2> oh yeah, our philipballew_ is now an ubuntu member :)
[01:48] <MarkDude> Good deal
[01:55] <philipballew> what up kdub!
[01:57] <MarkDude> philipballew, did they teach you the secret handshake?
[01:57] <philipballew> MarkDude yes, it's kinda painful...BIT SO WORTH IT!
[01:58] <MarkDude> lol
[02:22] <newboon2Age> Drew here, @ Ubuntu Hour: Mountain View;  aaditya akk pleia2 jtatum jledbetter crashsystems crashsystems1 outofjungle nigelb chaser broder markdude jmarsden jiboumans jamalta
[02:25] <MarkDude> Hey there newboon2Age
[02:25] <MarkDude> You going to Maker Faire this weekend? I have 1 extra ticket
[02:35] <newboon2Age> i would love to markdude. do we have s
[02:35] <newboon2Age> a table?
[02:35] <MarkDude> No table
[02:36] <jledbetter> newboon2Age, jtatum should be there any second now
[02:36] <MarkDude> I have tickets as well as a few 50% off cards
[02:38] <MarkDude> Caltrain is kinda near I think
[02:39] <newboon2Age> yes markdude i think you are right
[02:54] <newboon2Age> we'll have to adjust things because there is an event on yhe second floor where we'd normally been meeting
[02:57] <akk> Two months in a row where the 3rd floor is really busy. Wonder if they're less busy on some other day of the week?
[03:07] <newboon2Age> well still come akk - we will adjust
[03:08] <akk> can't make it this week, just got home from the pii conference (which was great)
[03:12] <newboon2Age> we'll miss ya akk
[04:06] <pleia2> ubuntu hour \o/
[04:10] <akk> yay pleia2
[04:27] <newboon2Age> pleia2, Michelle and Nagappan joined jtatum and i.  Micichelle is showing off a few of her many tek toys
[04:40] <newboon2Age> michelle just put 10.04 (from my pen drive) and is running Xournal x61T Thinkpad
[04:43] <akk> Nice!
[05:43] <philipballew_> can somebody try to fill the holes in my computer problem. my usb wi fi card wont work on my 10.04 desktop?
[06:18] <nhaines> philipballew_: congratulations!  \o/
[06:26] <philipballew_> ^ Thanks!!!
[17:45] <jamalta> what day are you all going to maker faire?
[17:46] <pleia2> not sure who all is going besides MarkDude
[17:46] <jamalta> Ah, alright :)
[17:47]  * MarkDude is
[17:47] <MarkDude> with like 8 people
[17:48] <MarkDude> Will tell folks about it- that is of course if the Rapture does not happen at 6pm local time
[17:51] <pleia2> MarkDude: jamalta asked which day you are going :)
[17:56] <MarkDude> My bad- Saturday
[17:57] <MarkDude> Rapture day
[17:57]  * pleia2 plans to be on the beach for it
[17:58] <MarkDude> If I dont see you before then pleia2 - it was nice knowing you ;)
[17:58] <MarkDude> philipballew, I will be going Saturday
[17:58] <pleia2> MarkDude: haha, same!
[17:59] <MarkDude> You still have time to check for things you have not done yet
[18:00] <MarkDude> make your own todo-list is my suggestion to everyone
[18:16]  * broder might be there
[18:27] <pleia2> http://loco.ubuntu.com/teams/ubuntu-california now has pictures from our flickr feed :)
[18:27] <pleia2> and reminder: if anyone wants to upload to our flickr feed, let me know
[18:28] <pleia2> (I can give you access, or you can email me your photos, or whatever)
[18:30] <MarkDude> I will - later tho


[10:08] <alan_g> alf_: vt switching bug lp:1465585
[10:08] <alf_> alan_g: thanks
[10:57] <tjaalton> mesa doesn't build on wily due to mir abi changes
[10:57] <tjaalton> so egl-platform-mir.patch needs an update
[10:59] <alf_> tjaalton: I will take a look
[10:59] <tjaalton> thanks
[10:59] <tjaalton> http://pastebin.com/RGP7Bt68
[10:59] <tjaalton> is the error
[11:00] <tjaalton> if it's something simple I can apply it directly and upload a new mesa
[11:00] <tjaalton> since I have 10.5.7 merged and ready
[11:06] <tjaalton> btw, mir source package still refers to the old lp branch
[11:06] <tjaalton> in debian/control
[11:20] <alf_> tjaalton: This package dependency problem in mir. If you want a quick solution to unblock you until we fix it, you can add a build dependency on libmirclient-dev.
[11:24] <tjaalton> alf_: ah, ok I'll try that
[11:29] <tjaalton> alf_: yeah that fixed it, thanks
[11:29] <alf_> tjaalton: yw
[11:38] <alf_> tjaalton: Is there a branch holding the packaging of mesa? lp:ubuntu/mesa seems not to contain recent updates?
[11:39] <alf_> tjaalton: ah, found it: http://git.debian.org/?p=pkg-xorg/lib/mesa.git
[11:40] <tjaalton> alf_: yeah that's it
[11:40] <tjaalton> just pushed the branch
[12:10] <alf_> tjaalton: FYI, https://bugs.launchpad.net/mir/+bug/1465642, I will let you know when this change reaches wily, so you can remove the workaround
[12:11] <tjaalton> ok cool
[13:46] <alan_g> alf_: was there any follow-up planned to your initial end-end test harness? I remember we discussed various options in Dallas...
[13:48] <alf_> alan_g: I think the discussion was for the end-to-end latency tests (which I haven't made any progress on).
[13:49] <alan_g> alf_: yeah, that's what I was wondering about. We landed mir_privileged_tests didn't we?
[13:52] <alf_> alan_g: Yes (and are enabled in CI). At the moment these only test that kernel input events reach clients, they don't perform any latency measurements/checks.
[13:53] <alan_g> alf_: OK. That's what I was wondering about. Thanks
[14:02] <alf_> alan_g: When you get some time, could you please check that https://code.launchpad.net/~afrantzis/mir/fix-1465585-1465669-one-input-dispatcher-to-rule-them-all/+merge/262088 solves the VT issue for you. I was getting something but not sure if it is exactly what you bug was about.
[14:03] <alf_> alan_g: "I was seeing something similar, but not sure..."
[14:05] <alan_g> alf_: ack. After I finish documenting the latest input bug I've found.
[14:09] <alf_> alan_g: Does purge-titlebars solve the same problem with GL you were referring to earlier today?
[14:09] <alan_g> alf_: yes
[14:09] <alf_> alan_g: Great \o/
[14:21] <alan_g> alf_: fixes 1465585
[14:22] <alf_> alan_g: thanks
[14:24] <alf_> kdub: @allocate-and-release-buffers-protobuf, can the allocate_buffers() call allocate buffers independently of a buffer stream?
[14:24] <kdub> alf_, no
[14:26] <alf_> kdub: ok, so 1. why is BufferStreamId optional and 2. why do we need to respecify buffer parameters, don't all buffers have the same parameters specified when creating the buffer stream?
[14:29] <kdub> its optional because optional fields were recommended somewhere on the protbuf site (bit hazy memory, but still abide by the advice)
[14:29] <kdub> I guess makes things easier to deprecate in the future
[14:30] <kdub> and for 2), I don't think we're having the constraint that all buffers have to be the same size
[14:30] <kdub> in the same stream
[14:31] <kdub> most the time they will... but I think for resize it might be helpful to have different sizes transiently
[14:34] <kdub> i have a sneaking suspicion that certain mm decoders might appreciate that too
[14:36] <alf_> kdub: right, but I am not sure if we will need to explicitly allocate buffers of mixed sizes. We will get mixed sizes as we allocate buffers (of new size) and release buffers (of the old size).
[14:42] <kdub> alf_, I guess I'm imagining more of a client-cooperating resize
[14:42] <kdub> where they get a resize event informing it of its "ideal onscreen size" and it will allocate buffers (if it can) to fit that size, and start sending those
[14:43] <kdub> and release the old-sized buffers when the client is done with them
[14:43] <kdub> hence the side discussion about separating mg::Renderable::screen_position() from mg::Buffer::size() a bit more
[14:44] <kdub> side-discussion & card, I should say
[14:46] <alf_> kdub: I don't get how the scenario you are resizing requires the client to _allocate_ buffers of mixed sizes (I agree that the buffer stream will end up having mixed sizes as the client allocates/releases)
[14:47] <kdub> well, if the client starts getting unrequested buffers as part of the server-initiated resize event, I guess it then has to free them
[14:49] <kdub> and, if the client is designating which of its many buffers to use, it can always just say 'use the badly-sized one' if it wants... the client has to cooperate with the resize, and letting it request buffers that it thinks are best seemed the way to go
[14:53] <alf_> kdub: Perhaps I haven't made myself clear enough... I am not concerned about the client allocating custom sizes, I am doubting the usefulness of being able to allocate mixed sizes in a single call e.g. (100x100, 50x50, 10x10) vs (100x100,100x100,100x100)
[14:53] <alf_> kdub: But the price we pay is small enough (and we are indeed a bit more versatile), so I guess I don't mind in the end
[14:54] <alf_> kdub: primarily wanted to know if there was a scenario that absolutely needs this
[14:54] <alf_> kdub: which I was missing
[14:54] <kdub> alf_, I started out with one buffer/call, but it seemed that some batching (esp for release) would just mean less ipc (in rev 2661 of the branch)
[14:55] <alf_> kdub: I am OK with release, mostly concerned with allocate, but I am OK with that too :)
[14:56] <kdub> and right, I guess its just for versatility
[14:56] <kdub> I guess (and its stretching a bit) maybe a decoder might want a spare smaller p-frame hanging around, whereas it mostly allocates full-resolution buffers
[15:34] <kdub> anymore takers on: https://code.launchpad.net/~kdub/mir/multiple-bufferstream-api/+merge/261123 (otherwise will TA shortly)
[15:43] <alan_g> kdub: you have enough "Approve" by A* without me. ;)
[15:44] <kdub> :) the "A team"
[17:21] <AlbertA> @vogons: well looks like there are issues loading both libmirclient.so.8 and libmirclient.so.9 at the same time after fixing the protobuf issue...
[17:21] <AlbertA> no crashes, just can't get a connection....
[17:22] <AlbertA> global var issues?
[17:23] <AlbertA> libmirclient.so.9 is loaded because the mesa client platform module links against it....
[17:23] <AlbertA> but the ABI number of the modules themselves has not changed
[17:27] <kdub> groan
[17:34] <AlbertA> it seems the local scope from symbols.map is gone...hmmmm
[19:45] <AlbertA> @vogons: so fixed the issue with the libmirclient symbols....it looks like using the protobuf xxx::default_instance().New() is enough to address the issue...so mir 0.13.3 is on
[19:48] <camako> AlbertA... great!
[22:49] <kgunn> vogons anyone know about the race between mir and agetty ?
[22:50] <kgunn> i was wondering...if you lose the race, what's a way to undo the loss ?
[22:51] <kgunn> like can i just kill the agetty process ?
[22:51] <kgunn> or is there some other clean up or something that needs to happen ?
[22:52] <kgunn> ok, need to bail for a little... still post here, but email as well if i'm still off
[23:00] <AlbertA> kgunn: umm not quite sure...what's the issue? both starting at the same time and either agetty wins the vt or not?
[23:00] <AlbertA> kgunn: can it be in a different VT?
[23:45] <RAOF> Yay! I left this code in an uncompilable state, so there's an obvious entry point.
[23:45] <RAOF> Go me!


[12:19] <Guest38> Will lubuntu 24.04 make the full transition from X11 to wayland utilizing lwqt?
[14:30] <arraybolt3[m]> Currently the LXQT developers have no ETA on when LWQT will arrive. There's a really big and messy GitHub bug report that has the discussion about it that I can find. Once that happens, it will be possible for us to consider transitioning over (which I know is something the devs are interested in once possible).
[14:31] <arraybolt3[m]> Guest38: ^
[14:32] <arraybolt3[m]> https://github.com/lxqt/lxqt/issues/10
[14:32] <arraybolt3[m]> Guest38: ^
[14:47] <Guest80> Is there an option to enable trusting .desktop files by default?
[14:50] <arraybolt3[m]> Not that I'm aware of.
[14:52] <Tiberi> you meaning right click and "trust this executable"?
[14:53] <Tiberi> any ideas my rebooting/shutdown problem?
[14:53] <Guest80> Yea. I just want to trust executables by default. Feels silly to have to do that with the qterminal the distro came with.
[14:54] <Tiberi> don't need to do that on qterminal
[14:54] <Guest80> I put a shortcut on the desktop (22.04.1) and I had to trust it.
[14:55] <arraybolt3[m]> Tiberi: Sorry, I don't know what's happening with the rebooting/shutdown problem, and I'm not even sure where to start looking. :(
[14:56] <Guest80> Isn't trust executable the same thing as doing chmod +x <program> in the terminal?
[14:58] <Tiberi> how about right click desktop file on desktop and that way?
[14:59] <Tiberi> someone said that they installed nvidia drivers, but don't know how to do that
[15:00] <tomreyn> Tiberi: i can look over your log if you like, but would need to see it fully. you can output the first and last 1000 lines of a boot where the system failed to shut down properly online like this: journalctl --list-boots    then look for which is the right boot ID. assuming it is ID "-3": journalctl -b -3 | head -n1000 | nc termbin.com 9999; journalctl -b -3 | tail -b 1000 | nc termbin.com 9999
[15:01] <Tiberi> ok
[15:01] <arraybolt3[m]> Tiberi: To install NVIDIA drivers, open "Software Sources" from the application menu, then click Additional Drivers, and select the NVIDIA driver of your choice (probably the one marked as being recommended). Then you can install it from there.
[15:04] <Guest80> I have another question: What is the name of the screen locker that lubuntu uses by default. Arch wiki says it uses slock or XScreenSaver. I just want to know what lubuntu picked.
[15:06] <Tiberi> tomreyn tail: cannot open '1000' for reading : no such file or directory?
[15:07] <tomreyn> Tiberi: sorry, i had a typo, this is correct:
[15:08] <tomreyn> journalctl -b -3 | head -n1000 | nc termbin.com 9999; journalctl -b -3 | tail -n 1000 | nc termbin.com 9999
[15:08] <tomreyn> note, again, the "-3" is just an example here
[15:08] <Tiberi> yeah but i think it is right one??
[15:09] <Tiberi> https://termbin.com/5jo4x
[15:09] <tomreyn> i could/would not know
[15:09] <Tiberi> https://termbin.com/ayf6
[15:11] <tomreyn> !acpi_osi | Tiberi: this is another approach you can try
[15:13] <tomreyn> ACPI Warning: SystemIO range 0x0000000000004E00-0x0000000000004E3F conflicts with OpRegion 0x0000000000004E00-0x0000000000004E3F (\_SB.PCI0.SM00) (20210730/utaddress-204)
[15:14] <tomreyn> ACPI: OSL: Resource conflict; ACPI support missing from driver?
[15:14] <tomreyn> this *may* be an issue, not sure
[15:15] <tomreyn> also this: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
[15:16] <Tiberi> how i do that?
[15:17] <tomreyn> !bootparm
[15:17] <tomreyn> !bootparam
[15:17] <tomreyn> sorry, let me find the right trigger
[15:18] <tomreyn> !kernelparm | Tiberi
[15:21] <tomreyn> this is old hardware with an nvidia graphics chipset. if there are problems which can be graphics related, and the (currently used) open source nouveau driver does not work well with it, maybe you can find a proprietary driver which still works with it.
[15:28] <tomreyn> this looks unrelated but wrong:  NetworkManager[762]: <info>  [1660767579.0958] failed to open /run/network/ifstate
[15:28] <tomreyn> networkd-dispatcher[771]: No valid path found for iw
[15:30] <tomreyn> also this looks wrong: snapd[784]: snapmgr.go:363: cannot read snap info of snap "gtk-common-themes" at revision 1535: cannot find installed snap "gtk-common-themes" at revision 1535: missing file /snap/gtk-common-themes/1535/meta/snap.yaml
[15:32] <tomreyn> Tiberi: oh, looks like your ata1.00 port HDD is just broken. no surprise on a 13y+ old device
[15:33] <Tiberi> nice
[15:33] <Tiberi> how that effect on shutting down?
[15:34] <tomreyn> well that has effects on any data that needs to be written, and sometimes also read, to / from disk. during shutdown, usually more data is written to disk than during standard operation
[15:34] <Tiberi> but somehow works kind of well. some little stucks, but..
[15:35] <tomreyn> well, backup asap what you can
[15:35] <Tiberi> why i does that thing allways?
[15:35] <Tiberi> it is just installed and i dosen't have anything
[15:35] <tomreyn> are you asking me why you're trying to run a 13+yr old computer?
[15:36] <Tiberi> just thinking why it stuck every time and same place on shutting down
[15:37] <tomreyn> get a new computer, or at least a mediocre ssd, it will still be a much better experience than it is now.
[15:37] <tomreyn> also this is just going to fail soon
[15:42] <Tiberi> i got new ssd on it
[15:55] <tomreyn> Tiberi: the WDC WDS240G2G0A seems to be what's broken
[15:56] <Tiberi> hmm..
[15:57] <tomreyn> WDC WDS240G2G0A-00JH30 specifically
[15:58] <tomreyn> first log says: ata1.00: ATA-9: WDC WDS240G2G0A-00JH30, UF510000, max UDMA/133
[15:58] <tomreyn> second log says:
[15:58] <tomreyn> systemd[1019]: Starting Virtual filesystem service...
[15:59] <tomreyn> kernel: ata1.00: exception Emask 0x10 SAct 0x300000 SErr 0x400000 action 0x6 frozen ... interface fatal error
[15:59] <tomreyn> it could also be a broken sata cable, though
[16:00] <Tiberi> laptop so it dosen't have sata cable
[16:00] <tomreyn> or loose connector
[16:00] <Tiberi> maybe solderings is bad?
[16:01] <tomreyn> then you'd always had this issue
[16:03] <Tiberi> even then i dosen't rebooted when i installed linux on usb stick
[16:09] <Tiberi> i don't know what should i try that i could only shutdown
[16:15] <tomreyn> https://support-en.wd.com/app/products/product-detailweb/p/279 provides a windows firmware updater for your ssd. this might be worth a try, too
[16:20] <Tiberi> how that works without windows?
[16:21] <Tiberi> ok i put it on my windows pc
[16:23] <Tiberi> or don't know how that works on windows
[16:55] <tristan_> hi
[16:55] <tristan_> tp link connection to my lap keeps disconnecting
[16:56] <tristan_> but other wifi connects good
[16:56] <tristan_> can anyone help?
[16:56] <tomreyn> Tiberi: https://wddashboarddownloads.wdc.com/wdDashboard/DashboardSetup.exe
[16:57] <Tiberi> yea i need to first put it on my windows pc
[16:57] <tomreyn> Tiberi: once you have it running, it should be pretty self-explanatory. there will be some "update"  or "FW upgrade" section or button, and then it should already select the right firmware
[16:58] <Tiberi> hope it work coz i dosen't have "windows" partitions
[16:59] <tomreyn> on the ssd? that wont matter
[17:12] <tomreyn> tristan_: try disabling power saving: https://gist.github.com/jcberthon/ea8cfe278998968ba7c5a95344bc8b55
[17:12] <tristan_> i did it
[17:13] <tristan_> if i restart router, wifi is working for some time
[17:14] <tristan_> only laptop has disconnection problem
[17:14] <tristan_> android phones working well with wifi
[17:14] <tristan_> if restart network manager it will connect for few seconds
[17:15] <tristan_> then keeps disconnect until restart router again
[17:15] <tristan_> other wifi with same laptop working fine
[17:15] <tristan_> i am using lubuntu 18.04
[17:20] <arraybolt3[m]> tristan_: Lubuntu 18.04 is EOL and unsupported. You might have better luck if you upgrade to the latest supported release, Lubuntu 22.04.
[17:21] <arraybolt3[m]> (Back up your data before beginning an upgrade since upgrades can go wonky.)
[17:22] <tristan_> is 22.04 comes with lxde?
[17:23] <arraybolt3[m]> Lubuntu upgraded to LXQt, which is a port of LXDE to the Qt toolkit. It looks pretty nice, but is a significantly different look and feel. (LXDE is being sunset in favor of LXQt by the upstream developers.)
[17:24] <tristan_> is lxqt fast like lxde?
[17:24] <arraybolt3> From my experience, yes. Works very well on systems with 2 GB of RAM or more.
[17:25] <tristan_> i need to take backup, i don't want to break anything.
[17:25] <arraybolt3> Very important. Definitely do that first.
[17:26] <arraybolt3> Oh, one more thing - do you know if your system is 32-bit or 64-bit?
[17:26] <tristan_> 64bit
[17:26] <arraybolt3> Nice, then you're good to go.
[17:26] <tristan_> i3 6th gen
[17:27] <arraybolt3> Oh wow. Yeah, that will work extremely well. I'm on i5 3rd gen over here and Lubuntu works awesome for me.
[17:27] <arraybolt3> s/will/should/ (since there's always a possibility of things going wrong, but that's why we're here to help fix that.)
[17:28] <tristan_> i liked lubuntu a lot
[17:28] <tristan_> easy ui
[17:32] <Tiber> firmware was up to date
[17:32] <Tiber> and healt was 99%
[17:35] <dragon2> lubuntu runs on old and new pcs
[17:35] <dragon2> probably with minimal specs too, but I haven't tried latey
[17:36] <Tiber> ?
[17:36] <dragon2> If you really want to, it will probably run on low specs, the trouble with turn when streaming videos, youtube, gaming, ....,
[17:37] <arraybolt3> dragon2: Welcome to the Lubuntu tech support channel! If you don't mind, we're mid support session. However, #ubuntu-discuss and #lubuntu-offtopic would be fantastic spots for this conversation.
[17:37] <arraybolt3> Tiber: Did you try the acpi-osi thingy yet?
[17:38] <Tiber> no
[17:38] <Tiber> what's that?
[17:38] <arraybolt3[m]> Lemme find it again...
[17:38] <arraybolt3[m]> !acpi_osi
[17:39] <arraybolt3> That describes exactly the problems you're running into IIUC, and gives a possible fix.
[17:39] <Tiber> ok i will try that
[17:46] <Tiber> damn... that should have step by step instructions for me
[17:47] <arraybolt3> Oh... OK, download the acpi_osi.sh script.
[17:49] <arraybolt3> Then open a terminal in the Downloads folder, and run "chmod +x ./acpi_osi.sh && ./acpi_osi.sh".
[17:49] <arraybolt3> Er, wait...
[17:50] <arraybolt3> chmod +x ./acpi_osi.sh && sudo ./acpi_osi.sh
[17:50] <arraybolt3> Tiber: ^
[17:53] <Tiber> ok and that's it?
[18:23] <Tiber> not shutting down
[18:29] <tomreyn> Tiber: it cannot have any effect until *after* the next reboot
[18:34] <Tiber>  https://termbin.com/u2p2  https://termbin.com/69re
[18:34] <Tiber> is this looking right?
[18:35] <Tiber> some one got same laptop as i and he speaked something about nvidia drivers
[18:36] <Tiber> now i can't see errors
[18:37] <Tiber> i should have nvidia 340 drivers
[18:41] <Tiber> https://unix.stackexchange.com/questions/623159/ubuntu-shutdown-does-not-power-off-tried-other-solutions
[18:41] <Tiber> that last one got same laptop as i
[18:43] <tomreyn> https://termbin.com/69re has the same error messages
[18:43] <tomreyn> ... as before
[18:43] <tomreyn> was the firmware upgraded?
[18:44] <tomreyn> did you run a health check?
[18:45] <tomreyn> it's entirely possible that the symptoms you described and the disk freezing are separate issues, though
[18:46] <tomreyn> it could also be that the ssd is just running too hot
[18:47] <tomreyn> 13yo laptops would have veeeery dirty /crammed fans unless you cleared those recently
[18:48] <Tiber> i have
[18:49] <Tiber> and firmware was upgraded and healt was 99%
[18:51] <Tiber> i have changed pii things and cpu is still being hot on windows 10
[18:51] <Tiber> now on linux it's going kind of quiet
[18:56] <Tiber> i was going to use that laptop on pc osciloscop and maybe arduino ide
[18:57] <Tiber> windows 7 was last windows that i have actually used that
[19:09] <tomreyn> to detect thermal sensors, install lm-sensors and run sensors-detect.
[20:03] <Tiber> i think i make i right but everything is no
[20:31] <Tiber> how i can install nvidia-legacy-340 ?
[20:32] <Tiberi> GPG error: http://deb.debian.org/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY DCC9EFBF77E11517
[20:35] <Tiber> something that i don't know?
[20:36] <Tiber> or i don't know anything actually