[03:00] <marc_> hey
[13:33] <BluesKaj> Hi all
[15:07] <kubuntu> can I please get help with a problem I have with Kubuntu live
[15:10] <kubuntu> Anybody out here ???
[15:10] <kirvesAxe> Don't ask to ask, just ask...
[15:12] <kubuntu> Thanks. I installed Kubuntu live on a USB stick and evrything works well. However when I install new programs and then restart the computer all installed programs are gone
[15:13] <kubuntu> How can I save the new installed programs after a reboot ???
[15:18] <diogenes_Vx15> kubuntu, are you sure you installed the system and not running it off a USB?
[15:18] <kubuntu> Yes running it from a live usb stick
[15:19] <kubuntu> Or isn't that considered as an installed version. It starts with Try Ubuntu
[15:19] <diogenes_Vx15> kubuntu, running it from a live USB stick is not considered installed system.
[15:20] <kubuntu> ok, so it will not remember anything after a reboot ???
[15:21] <diogenes_Vx15> kubuntu, yes it will not remember anything after a reboot.
[15:22] <kubuntu> that explains. Thanks. Any info on how I do an USB install then ??? Can I do the install from the USB stick on that same USB stick ???
[15:24] <diogenes_Vx15> kubuntu, that's not so easy to do.
[15:25] <kubuntu> Ok I'll try something different. Install the Live version on a smaller USB stick and then use Install Kubuntu on a different USB stick
[15:27] <kubuntu> Thanks


[00:08] <bac> hey rick_h_
[00:09] <rick_h_> bac: howdy
[00:09] <bac> i've gotten most things integrated and working.  may need to bug you in the morning to work out why the heights aren't what i expect.
[00:09] <rick_h_> bac: sure thing
[00:09] <bac> the charm panel has very tight specs for those sizings
[00:09] <rick_h_> ping me when you get in and we can run through it.
[00:09] <rick_h_> bac: k
[00:10] <bac> rick_h_: it is here if you're curious lp:~bac/juju-gui/hookup-resizing-textarea
[00:10] <bac> the single line inputs in the charm panel have to be 28px tall.  it took some weird tweaking to get them there
[00:11] <rick_h_> bac: yea, I think that's what that single input height was for. To kind of 'check' how tall each line of text should be
[00:11] <rick_h_> bac: I'll try to look at it in the morning and see
[00:12] <bac> rick_h_: i changed single_line to be either falsy or to take a height.  the LP version used 1em hard coded
[00:12] <bac> rick_h_: have a good night.
[00:12] <rick_h_> bac: you too
[01:35]  * hazmat watches gary_poster fill up the inbox in real time
[01:35] <gary_poster> :-)
[01:36] <hazmat> thanks
[01:36] <gary_poster> welcome (glad it is a good thing; was a bit worried about subscribing juju-gui but thought it was appropriate)
[01:38] <rick_h_> oh, is that why I'm getting dupes?
[01:38] <rick_h_> ok, thought I had done it wrong when I sub'd to everything
[01:50] <gary_poster> sorry rick_h_
[01:50] <rick_h_> gary_poster: no, all good. Was curious checking if they were new ones I missed/etc
[01:50] <gary_poster> :-)
[01:50] <gary_poster> I added three
[01:51] <gary_poster> added juju-gui for those
[01:51] <rick_h_> cool
[09:31] <frankban> morning rogpeppe
[09:32] <rogpeppe> frankban: hiya
[09:32] <frankban> bug 1160971 seems fixed, I attached the script used to dupe it, now it works well, do you want me to mark it as fix release in juju-core?
[09:32] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent <juju-core:New> <juju-gui:Fix Committed> <https://launchpad.net/bugs/1160971>
[09:33] <rogpeppe> frankban: cool. i thought it probably was but your pastebin has disappeared so wanted to check with you
[09:33] <rogpeppe> frankban: it's incredibly annoying that pastebin has lost everything
[09:33] <frankban> rogpeppe: yes, it's not a reliable tool for this kind of things
[09:34] <rogpeppe> frankban: tbh i think they have a responsibility to keep all the pastes around
[09:34] <rogpeppe> frankban: they're a specific kind of history and really quite important
[09:36] <frankban> rogpeppe: I agree, IIRC there was some discussion in some ml about this issue.
[09:37] <frankban> rogpeppe: anyway, marking it as "fix released" if you agree.
[09:37] <rogpeppe> frankban: in particular a lot of IRC discussion logs will be less useful without the pastes
[09:37] <rogpeppe> frankban: sgtm
[09:39] <frankban> rogpeppe: cool. oh, and congrats for your spotlight award, you deserved it! :-)
[09:39] <rogpeppe> frankban: thanks!
[09:39] <rogpeppe> frankban: you guys have been awesome too
[09:40] <frankban> :-)
[11:42] <rick_h_> anyone know what the config is on the charm to not have it ask for the password? I'm not seeing a config option for that.
[11:46] <benji> rick_h_: as far as I can tell if you deploy to py-juju and set "staging" to true in the config, then it shouldn't request a password
[11:47] <rick_h_> benji: cool, /me goes to try
[11:48] <rick_h_> cool though, first time I've deployed juju-gui and into an environment with our charmworld stuff
[11:49] <rick_h_> sweet https://ec2-54-224-200-253.compute-1.amazonaws.com/bws/fullscreen
[11:50] <rick_h_> gary_poster: so this is a juju-gui using svg image links back to charmworld serving the svg image files working.
[11:50] <rick_h_> gary_poster: still no gzip, but I think it works out well
[11:52] <rick_h_> thanks benji, worked
[11:52] <benji> cool
[11:52] <rick_h_> <3 using uistage to look up charm config options and descriptions lol
[11:52] <rick_h_> dogfooding!
[11:52] <benji> :)
[12:09] <gary_poster> rick_h_, yeah, way better!
[12:10] <rick_h_> gary_poster: I think so. I'll bring it up in our stand up for review from others and then we'll see about breaking the work down into backend/front end cards
[12:10] <gary_poster> cool
[12:11] <rick_h_> and this has the charmworld server doing the correct trimmed OPTION request, so 231B pre-flight with 158K of data
[12:11] <rick_h_> so much better than over 1M
[12:12] <gary_poster> cool, rick_h_.  If you cache for switch between full and sidepanel then I think that will be a pretty good resolution
[12:12] <gary_poster> I mean, the combined package
[12:12] <rick_h_> gary_poster: right
[12:14] <gary_poster> rick_h_, so is that instance trunk, or a custom branch of yours?  I could update the sandbox version and then we could have this behavior on the demo if you want--and the sandbox will make it feel asnappier also
[12:15] <rick_h_> gary_poster: it's a custom branch of charmworld and juju-gui that just implemented a quick hack to proof it out
[12:16] <gary_poster> rick_h_, ok cool
[12:16] <rick_h_> gary_poster: so we have to go back and add the feature to charmworld, with tests, etc. and the front end
[12:16] <rick_h_> I actually really like this 'create a branch, hack feature in, launch charms, point at hack branches...test'
[12:17] <rick_h_> really kind of cool to A/B ish feature test
[12:17] <gary_poster> add feature and tests: yeah, understood rick_h_ .  Is that a "by the end of this week" thing, if it were prioritized, do you think rick_h_ (understanding that it might not be prioritized and your estimate might be wrong and la la la la) ;-)
[12:18] <gary_poster> rick_h_, cool to test with: agree.  lightweight deployment is very nice.  makes me want it even more lighter weight :-) particularly for iterative development and testing
[12:18] <rick_h_> gary_poster: I'll ask in the stand up. I think since it can make the demo better it will be my/abentley's goal for today, but not sure
[12:18] <gary_poster> cool
[12:19] <rick_h_> gary_poster: I do need a hand from someone in debugging an issue I've got that only shows in prod mode. however, when I try to run make prod I get 404's vs the app
[12:19] <gary_poster> huh
[12:19] <rick_h_> gary_poster: just at some point today if someone is experienced in how prodmode is setup/diff
[12:19] <gary_poster> rick_h_, yeah I know that.  now's about as good time as I'll get.  If we can't figure it out quickly I can hand it off
[12:19] <rick_h_> https://bugs.launchpad.net/juju-gui/+bug/1175183 only happens in production mode, but running that locally would 404 when I go to 127.../bws/fullscreen and such
[12:19] <_mup_> Bug #1175183: Filters checkboxes should not act as radio buttons <charmbrowser> <juju-gui:In Progress by rharding> <https://launchpad.net/bugs/1175183>
[12:19] <gary_poster> I mean, I know about that
[12:20] <gary_poster> ah
[12:20] <gary_poster> yeah
[12:21] <gary_poster> prod mode is simply dumber atm, in that the backing webserver can't serve index.html from arbitrary urls
[12:21] <gary_poster> so quick hack:
[12:21] <gary_poster> merge your "charmbrowser defaul" branch and debug
[12:21] <rick_h_> ah, gotcha. makes sense.
[12:21] <gary_poster> alternative, maybe quick hack:
[12:21] <rick_h_> thanks, will do
[12:22] <gary_poster> look at devel and try to switch that to serve prod temporarily
[12:22] <gary_poster> cool
[12:36] <gary_poster> benji, if you want to talk about memory, I have about 10 or 15
[12:36] <benji> gary_poster: sounds good.  the regular place?
[12:36] <gary_poster> sure benji
[12:39] <bac> hi rick_h_, thanks for your email and explanation
[12:40] <bac> rick_h_: upon further investigation i did see that the <input> fields on the charm panel have a line-height and height of 18px, so it is working just fine
[12:40] <rick_h_> bac: np, thinking it's the generic css rules from input -> textarea getting in the way if I'm lokoing at the right spot
[12:40] <bac> rick_h_: and those are the ones we're trying to match
[12:40] <rick_h_> bac: yep, that's what I was going to add today. I missed putting line-height in those css notes
[12:40] <rick_h_> so font-size, line-height, padding, border all come into the combined height you end up getting
[12:41] <bac> rick_h_: there is a problem with the service settings page, though.  if you still have my branch could you add haproxy and then look at http://localhost:8888/:gui:/service/haproxy/config/  when you have time?
[12:41] <rick_h_> bac: I can pull it back down. give me a few.
[12:48] <rick_h_> bac: ok, loaded and on that url
[12:48] <bac> so if you look down at service, one of the last ones
[12:49] <rick_h_> k
[12:49] <rick_h_> bac: ok, so this should be opened up?
[12:49] <bac> rick_h_: you'll see it is a single line, though it is populated with multi-line data.  a keypress in there will cause it to expand
[12:49] <bac> righto
[12:49] <rick_h_> k, /me goes and looks at code/etc for a bit
[12:50] <bac> i'm stepping through the resize() method called at the end of the initializer now.  that is where it is supposed to get expanded
[12:51] <rick_h_> bac: right, but in resize it checks for single_line and trumps the height in that first if condition I'd expect
[12:51] <bac> rick_h_: ah, i think maybe _prev_scroll_height should not be initialized to 0
[12:52] <bac> rick_h_: i see this behavior whether using single_line or now
[12:52] <bac> not
[12:52] <rick_h_> bac: so this was built to work with the inline editor such as the bug title, so that a single line would expand only when you were editing
[12:52] <bac> rick_h_: funny thing is it works in charm panel when using single_line
[12:52] <bac> in this view it does not work either way
[12:52] <rick_h_> bac: k, looking
[12:57] <rick_h_> ugh, multi dispatch FML. Goes through this debug code so many times
[12:58] <rick_h_> bac, what view is doing the initial work here? loading plugging the textareas?
[12:58] <rick_h_> bac: actually, want to chat for a second?
[12:59] <bac> sure
[12:59] <rick_h_> bac: looks like the normal hangout is taken, sec
[12:59] <bac> k
[13:00] <rick_h_> bac:  https://plus.google.com/hangouts/_/439096b6bd109b21f6137274b06438e42739fdb0?authuser=0&hl=en
[13:38] <gary_poster> rick_h_, I think I LGTM'd everything from Huw
[13:38] <rick_h_> thanks gary_poster
[13:39] <gary_poster> welcome
[13:44] <bac> hi gary_poster -- the integration with the resizing textarea is going well.  it works in the charm panel but is not happy in the service settings view.  rick and i know what's going on and i'm chasing it down.
[13:44] <gary_poster> awesome bac!
[13:44] <gary_poster> thanks for heads up
[13:55] <rick_h_> bac: after I cleared my browser 100x I did get it to hit those debuggers but the Y.Array.each wasn't seeming to get hit.
[13:55] <bac> rick_h_: similar here
[14:02] <rick_h_> bac: bah, you don't need to Y.Array.each a nodelist, you should be able to just do view.tareas.each(...
[14:02] <bac> rick_h_: i'm confused.  when the break point hits, view.tareas is an array with 12 elements.  the breakpoint inside the .each never hits, though
[14:02] <rick_h_> bac: if you get a sec try that. If not I'll give it a go after I get this stuff landed for huw
[14:06] <bac> rick_h_: that works if you do  tarea.resizingTextarea.resize(); -- the plugin must be included
[14:06] <rick_h_> bac: ah! awesome
[14:07] <rick_h_> bac: so at least a hack can make it work then. Might check with hatch or someone more up on showView() to see if there's a better place to hook into. A 'rendered' event or something. Otherwise, this gets around the issue at least
[14:07] <hatch> whaaaadauuupppp
[14:08] <bac> hey hatch
[14:08] <rick_h_> beetlejuice ... beetlejuice ...
[14:08] <hatch> BEETLEJUICE!!!!!!
[14:09] <bac> so in services.js views.service_config there is a container that i'm using to add the resizing textarea plugin
[14:10] <bac> hatch: all well and good, but that container has not yet been added to the DOM, so the initial size computations are all zero
[14:11] <rick_h_> hatch: I couldn't figure out how/when showView() from _buildServiceView() actually put the thing in the DOM
[14:12] <rick_h_> hatch: in app.js, so we put some hack code into the callback for post-showView() but feels hacky
[14:12] <bac> hatch: http://paste.ubuntu.com/5625996/
[14:13]  * hatch creates a card for everyone to use gist.github.com so we can have editing and syntax highlighting
[14:13] <hatch> ;)
[14:13] <rick_h_> hatch: replies!
[14:14] <rick_h_> paste.mitechie.com :) lodgeit ftw
[14:14] <hatch> sorry I had to run and take the garbage out....not that it mattered I missed the damn truck
[14:14] <hatch> gists are mini git repos, nothing beats that :)
[14:15] <hatch> bac: rick_h_ so that's how you're supposed to do it - th eonly change I would do is have a method you call in the view to do that each()
[14:15] <rick_h_> hatch: yea, makes sense. view.fixTextAreas()
[14:15] <hatch> haha - well....instantitateTextAreas :P
[14:16] <rick_h_> view.inTheDippyDomNow()
[14:16] <rick_h_> :P
[14:16] <hatch> view.lickyBoomBoomDown
[14:16] <hatch> view.informer
[14:17] <hatch> view.blam
[14:17] <hatch> name that song! first person wins 1 internet
[14:20] <benji> no, not Snow, anyone but Snow
[14:20] <rick_h_> lol
[14:21] <rick_h_> that just makes me want to start 'ice ice baby'ing around the house
[14:21] <bac> rick_h_, hatch: yeah perhaps we should not attach the plugin until after showview
[14:21] <benji> I'll take two Vanilla Ices (Icies?) over Snow
[14:21] <rick_h_> bac: or that.
[14:21] <hatch> http://www.youtube.com/watch?v=NtILxBszyf8
[14:21] <benji> Especially now that he is a general contractor with a renovation TV show
[14:21] <hatch> I want those sunglasses
[14:21] <hatch> lol
[14:22] <hatch> benji: haha really?
[14:22] <benji> yep
[14:22] <benji> who saw that career change coming?
[14:23] <benji> hatch: https://www.youtube.com/watch?v=IrNiiNRCvYo
[14:23] <hatch> vanilla ice !== snow :)
[14:24] <hatch> oh
[14:24] <hatch> sorry too early
[14:24] <hatch> missed the convo changing tracks
[14:24] <hatch> :)
[14:28] <hatch> jujugui - has anyone looked into these CI failures? I think this one is fixable
[14:29] <gary_poster> hatch, I tried yesterday.  sent email.
[14:29] <hatch> 2013-05-02 14:27:27,704 DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
[14:29] <hatch> oh woops sorry I'm 100+ behind in my emails
[14:29] <gary_poster> hatch, we must fix it.  make distfile might be broken?
[14:30] <hatch> possible, I'll grab my laptop and log into it
[14:30] <hatch> see what I can do to fix it
[14:32] <gary_poster> hatch make distfile works on trunk.  this is on charm apparently.  do you know where to find the right image numbers offhand?
[14:32] <gary_poster> if you can fix CI, teknico is looking at broken charm
[14:32] <hatch> isn't that euca-describe-images or something
[14:32] <hatch> was just looking it up
[14:32] <gary_poster> hatch something like that but then you have to know which one to choose of a zillion
[14:33] <hatch> I'll pick the one with the coolest name
[14:33] <gary_poster> heh
[14:33] <hatch> honestly I was going to see what the old one was and try and find something similar
[14:35] <frankban> gary_poster, hatch, teknico: it seems that make distfile is broken in trunk: http://pastebin.ubuntu.com/5626062/
[14:35] <hatch> oh ok
[14:35] <gary_poster> frankban, worked for me after make clean.  maybe make clean-all is necessary to trigger
[14:36] <frankban> gary_poster: oh, trying
[14:38] <hatch> ok well if you guys are on it i'll get back to gui stuff
[14:38] <frankban> gary_poster: still an error
[14:38] <gary_poster> hatch, multiple problems
[14:38] <gary_poster> hatch if you can fix image name that would be fanulous
[14:38] <gary_poster> fabulous even
[14:38] <frankban> (make clean-all && make distfile)
[14:39] <hatch> ohh ok
[14:39] <gary_poster> frankban, weird.  I got a fresh branch and WFM.  Raring, yeah?
[14:39] <rick_h_> gary_poster: FYI manage.j.c is updated with fixes to the OPTIONS request and gzip is now enabled so tinyurl.com/jujucharms should hurt less.
[14:39] <frankban> gary_poster: yes, trying on a branch
[14:39] <gary_poster> frankban, and the failure was the same as before ?  " bin/py: File removed before we read it" is weird error
[14:40] <frankban> gary_poster: yes
[14:40] <gary_poster> rick_h_, awesome thanks.  once fires are out I'll also update tinyurl.com/jujucharms
[14:46] <hatch> hmm I cannot remember how we specify the image to use
[14:46] <gary_poster> hatch in ~/.juju/environments.yaml
[14:47] <hatch> ohh right right
[14:50] <hatch> umm....image id's are in the format aXi-XXXXXXXX - the one in the env.yaml looks like a hash of some type
[14:51] <hatch> or am I missing something here?
[14:51] <frankban> gary_poster: it was a local problem: bin/py broken symbolic link in my trunk branch, not removed by make clean-all
[14:51] <gary_poster> frankban, ah ok cool.
[14:52] <hatch> so as far as images go - do we want 64bit raring?
[14:52] <gary_poster> hatch no
[14:52] <gary_poster> we want 64 bit precise
[14:52] <hatch> or stay with 12.04?
[14:54] <hatch> does anyone have any idea how that id got changed?
[14:54] <gary_poster> hatch 12.04
[14:55] <gary_poster> hatch the id changed probably because they have improvements to the image
[14:55] <gary_poster> newer sources
[14:55] <gary_poster> that sort of thing
[14:55] <hatch> no I mean they aren't even in the same format
[14:55] <hatch> the one in our env.yaml is a huge hash
[14:55] <hatch> not the format of the image id's
[14:56] <hatch> hmph who knows I'll keep it just in case
[14:57] <gary_poster> hatch, sorry, trying to get over at the machine to look.  have a call in 3
[14:57] <gary_poster> and was just off another call
[14:57] <hatch> sure np - I am just looking through the list of images
[14:57] <hatch> I think we want ubuntu-released image?
[14:57] <hatch> sounds like it would make the most sense :)
[14:58] <gary_poster> yes hatch I think so.  Although if it has "smoser" in the name it is fine too I think
[14:58] <hatch> there are those too but they are further down - I'll try this one for now
[14:58] <gary_poster> ok
[15:00] <hatch> ok id updated and new build kicked off
[15:00] <hatch> really wondering how that id got changed
[15:05] <hatch> hmm now it's saying invalid image ref provided
[15:05] <gary_poster> hatch http://<IP_ADDRESS>:8080/job/jujugui-test-charm/385/console
[15:05] <hatch> I'm confused...
[15:05] <gary_poster> not good image
[15:06] <hatch> ok will try the smore one
[15:07] <teknico> here are some charm changes, I'd like a few eyes on it, possibly frankban's, and bcsaller_'s when he's around: https://codereview.appspot.com/9121043/
[15:07] <teknico> I even did a pre-review of sorts to help you out :-)
[15:07] <hatch> kicked off build again
[15:08] <frankban> teknico: will do
[15:08] <teknico> frankban, thanks
[15:09] <hatch> ok invalid image ref again...it must not like the id format
[15:09] <hatch> so I need to somehow associate the id in the euca list to some hash?
[15:10] <hatch> according to the canonistack documentation it's the proper ID format
[15:11] <hatch> checking in #canonical-support
[15:12] <hatch> orr..... matsubara you around?
[15:12] <matsubara> hatch, yep
[15:13] <hatch> so we started getting these errors last week
[15:13] <hatch> DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}'
[15:13] <hatch> and when I view the environments.yaml file the ID is a large hash
[15:13] <hatch> but when I change it to a proper ID it gives me an invalid ref id
[15:13] <hatch> ERROR Unexpected 400: '{"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}'
[15:13] <matsubara> hatch, deploying on canonistack?
[15:13] <hatch> yeah
[15:14] <hatch> so it's like it's expecting a large hash ID not the one that's in euca-describe-images
[15:18] <matsubara> hatch, can you deploy locally from your laptop?
[15:19] <hatch> I can try
[15:19] <hatch> but I'm going to guess no
[15:19] <hatch> heh
[15:21] <hatch> that also has the large hash i'd
[15:21] <hatch> ids
[15:21] <hatch> I can't remember where those came from
[15:21] <hatch> but no - can't find the requested image
[15:21] <matsubara> hatch, sorry, got disconnected. I think smoser knows the id to use. maybe ask on #is?
[15:22] <hatch> ok so it doesn't follow the canonistack documentation on wiki any more?
[15:22] <hatch> the id's from euca-describe-images aren't valid?
[15:23] <hatch> ok I asked him
[15:24] <matsubara> hatch, this is in the env.yaml file for the charmworld project:  default-image-id: bb636e4f-79d7-4d6b-b13b-c7d53419fd5a
[15:25] <hatch> yeah same we have
[15:25] <hatch> which doesn't work
[15:25] <gary_poster> hey hazmat.  https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-read-only-for-is is the blueprint.  It is for juju-gui.  I think you need a juju-core blueprint.  That will be one that GUI follows
[15:25] <gary_poster> I think I should try to delet the gui one
[15:25] <gary_poster> e
[15:25] <hazmat> gary_poster, ack, thanks
[15:28] <matsubara> hatch, might be a problem on canonistack itself
[15:28] <hatch> just got an id - and an explanation as to what's up
[15:28] <hatch> so /me happy
[15:28] <matsubara> cool
[15:28] <rick_h_> noooooooooo bug in yui makes me sad...well at least lack of support
[15:29] <hatch> which bug?
[15:29] <gary_poster> hazmat, I was wrong: https://blueprints.launchpad.net/juju-core/+spec/servercloud-s-juju-core-role-based-access-control
[15:30] <gary_poster> have at it :-)
[15:30] <hatch> gary_poster: jenkins is about to shut down so when it's back we'll see if this new ID works...and I also found out why there is a discrepecy and will update the documentation
[15:30] <rick_h_> hatch: working on it. Looks like it has two query string parsers. One in http://yuilibrary.com/yui/docs/api/files/app_js_router.js.html#l994
[15:30] <rick_h_> hatch: and the query string module itself
[15:30] <gary_poster> hatch, and can you also document what to do in the future when this happens? :-)
[15:30] <hatch> rick_h_: keep in mind we have totally bastardized that router code :)
[15:30] <rick_h_> hatch: the one in the router code is dumb and can't handle  querystring: "category=databases&category=file_servers&
[15:30] <hatch> gary_poster: definitely - I was getting frustrated hah
[15:30] <rick_h_> where a key is in there twice to turn into an []
[15:30] <gary_poster> :-) cool
[15:43] <hatch> rick_h_: that's because query strings with multiple of the same keys are technically invalid :)
[15:44] <rick_h_> hatch: but but but
[15:44] <rick_h_> hatch: it works in dev mode :P
[15:44] <hatch> haha no I agree it's a commonly used feature
[15:45] <rick_h_> hatch: only fails in production so building tests against Y.QueryString and Y.Route atm
[15:45] <hatch> oh really? that's interesting
[15:46] <rick_h_> hatch: http://jsbin.com/efofol/1/
[15:47] <rick_h_> hatch: so for some reason in dev it's using Y.QueryString but in production using Y.Router._parseQuery and thus breaking my filters
[15:47] <rick_h_> hatch: anyway, will ahve to find some way to cheat it when I get back from lunch. bbl
[15:48] <hatch> ohhhhh
[15:48] <hatch> now I see what's going on
[15:50] <gary_poster> juju kanban now please
[15:50] <gary_poster> jujugui I mean
[15:51] <gary_poster> bcsaller, any idea when your branch might land?  if soon I will wait to update tinyurl.com/jujucharms
[15:53] <bcsaller_> gary_poster: I pushed a number of updates a minute ago, I think I if I could get a second review on https://codereview.appspot.com/9070043/ I'm ok with it as an intermediate step
[15:54] <gary_poster> bcsaller_, cool, let's rustle someone up on the call
[15:54] <bcsaller_> redoing the propose now
[15:55] <bcsaller_> gary_poster: did you ever get it to work in practice?
[15:55] <gary_poster> bcsaller_, aigh! no!  doing now.
[15:58] <gary_poster> bcsaller, lol that's *awesome*
[15:58] <bcsaller_> heh :)
[15:58] <gary_poster> bcsaller_, I will have to do a live demo on call :-P
[15:59] <gary_poster> bcsaller_, qa: cannot add or remove relations to imported bits
[16:00] <gary_poster> maybe fixed
[16:00] <gary_poster> but just pulled
[16:00] <gary_poster> oops
[16:00] <gary_poster> jujugui call nowq
[16:00] <bcsaller_> gary_poster: yeah, should work now
[16:05] <bac> jovan2: i'd like you to look at the expanding textareas.  i have an instance coming up at http://ec2-50-19-207-147.compute-1.amazonaws.com and it will be available soon
[16:05] <bcsaller_> https://codereview.appspot.com/9070043/
[16:06] <jovan2> bac: sure
[16:12] <jovan2> bac: pwd?
[16:12] <frankban> Makyo: congrats!
[16:12] <Makyo> Thanks :)
[16:15] <Makyo> I found out this morning we made a couple of the local papers, too, since it was the first day. :P
[16:16] <bac> jovan2: trying to get it
[16:18] <teknico> bcsaller_, frankban, thanks for the reviews!
[16:23] <hatch> LF review for doc update https://codereview.appspot.com/9124043/
[16:24] <gary_poster> hatch, maybe mention how to choose the ids?  look for precise, and...?
[16:24] <hatch> now that the CI is back up we have failures in IE
[16:24] <gary_poster> :-(
[16:24] <hatch> gary_poster: adding
[16:24] <gary_poster> thanks
[16:27] <hatch> gary_poster: proposing
[16:28] <bac> hey rick_h_, could you look at the above ec2 url?
[16:29] <hatch> updated
[16:31]  * bac lunches
[16:33] <rogpeppe> gary_poster: "the Juju API cannot accept a websocket directly (it expects to have to upgrade it)"
[16:33] <rogpeppe> gary_poster: what does that mean?
[16:34] <gary_poster> rogpeppe, it may be no longer relevant,  Where is that? on call
[16:34] <rogpeppe> gary_poster: it's from servercloud-s-juju-core-role-based-access-control
[16:37] <gary_poster> rogpeppe, could you delete? not relevant
[16:39] <rogpeppe> gary_poster: ah actually - i'd missed the fact that that comment was talking specifically about py juju
[16:39] <rogpeppe> gary_poster: so probably still relevant
[16:39] <gary_poster> yes
[16:48] <hatch> bac: did you test your textarea stuff in IE? it looks like it's breaking the CI
[16:48] <hatch> sorry... :)
[16:57] <Makyo> hatch, It hasn't landed yet, has it?
[16:58] <hatch> the video shows a 'textarea' suite failing
[16:58] <Makyo> Was it landed as separate branches, then?
[16:58] <hatch> I can't seem to stop the video to see what the title actually says
[16:58] <hatch> I have no idea
[17:16] <gary_poster> hatch, some of it landed a while ago
[17:16] <gary_poster> specifically some standalone plugin tests
[17:16] <gary_poster> IIRC
[17:17] <gary_poster> the new branch actually integrates it
[17:17] <hatch> ohh ok - looks like it's those tests which are failing in IE
[17:18] <gary_poster> bac, LGTM with comments plus fixing the IE tests from previous checkin
[17:21] <gary_poster> benji did you run the charm tests when you landed?  teknico reported that tests were broken in trunk
[17:23] <gary_poster> frankban, LGTM.  Did deploy tests also fail for you?
[17:24] <frankban> gary_poster: not tried, teknico said they were failing in trunk, I suggested to handle that in another card. I can check it tomorrow
[17:24] <gary_poster> ok thanks frankban.  have a good evening
[17:24] <frankban> gary_poster: you too!
[17:30] <gary_poster> bcsaller_, I still cannot add or remove relations on imported services with tip of your branch
[17:31] <bcsaller_> gary_poster: yeah, I loaded the charms so I thought it would work, I'm looking at that now, very odd error
[17:31] <bcsaller_> this.db.charms.get('id')
[17:31] <bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-14", "cs:precise/mysql-19", "cs:precise/mediawiki-8", "cs:precise/haproxy-17"]
[17:31] <bcsaller_> app.db.charms.get('id')
[17:31] <bcsaller_> ["cs:precise/memcached-6", "cs:precise/wordpress-10", "cs:precise/mysql-16", "cs:precise/mediawiki-6", "cs:precise/haproxy-16"]
[17:31] <bcsaller_> where 'this' is the fakebackend
[17:31] <hatch> that's a lot of smiley faces
[17:32] <bcsaller_> hatch: you have a very expressive IRC client
[17:32] <hatch> yeah it even does inline pastebins, images, and autoresolves tinyurls
[17:34] <gary_poster> bcsaller_, weird...so fakebackend is not honoring the service revision
[17:34] <gary_poster> bcsaller_, maybe it can't honor it?
[17:35] <bcsaller_> gary_poster: or they are pulling from the old and the new sources
[17:35] <gary_poster> bcsaller_, because the charm store only offers current versions?  and so the solution is to reconcile?
[17:35] <gary_poster> on the service
[17:36] <gary_poster> bcsaller_, I think that is it: line 325 of fakebackend
[17:36] <gary_poster> this.get('charmStore').loadByPath(
[17:36] <gary_poster>             charmIdParts.charm_store_path
[17:37] <gary_poster> if you go get that json...
[17:37] <bcsaller_> I suspect you're correct
[17:40] <gary_poster> bcsaller_, yup: http://jujucharms.com/charms/precise/wordpress-10/json (look for store_revision and compare with url)
[17:40] <gary_poster> or store_url for that matter
[17:41] <bcsaller_> the the imports are not going be the current version much of the time anyway
[17:41] <gary_poster> yeah
[17:41] <gary_poster> arguably would be more reliable if they were
[17:41] <bcsaller_> but its not quite like pinning a package version
[17:41] <gary_poster> in terms of backwards compatibility
[17:42] <gary_poster> it kind of should be
[17:42] <bcsaller_> within a series the assumption has been that current == best
[17:42] <gary_poster> no guarantee that config will be the same across revisions, or relations, or...
[17:42] <gary_poster> but that's not an option right now anyway
[17:43] <gary_poster> I think we ought to continue to ask for what the import specifies, but update the service to the charm we actually get and hope for the best
[17:43] <bcsaller_> yeah, npm styled specs in the charm for revisions might be nice some day, an export format that could say charm: "cs:precise/wordpress >= 10"
[17:43] <gary_poster> yeah
[17:44] <bcsaller_> I can do an inplace upgrade for now, yeah
[17:44] <gary_poster> cool
[17:49] <gary_poster> bcsaller_, the new promise code is not working in fakebackend.  charms are being loaded because of the GUI side endpoints code
[17:50] <gary_poster> bcsaller_, to demonstrate put breakpoint in line 1253 (if (s.name && !s.id)) in fakebackend
[17:50] <gary_poster> bcsaller_, s.id is always set
[17:50] <gary_poster> so _promiseCharm never called
[17:50] <gary_poster> at least with sample-fakebackend.json
[17:51] <hatch> is this something I did?
[17:51] <bcsaller_> hmm, sounds like I've got some digging to do
[17:51] <hatch> I saw promise and charm
[17:51] <gary_poster> hatch no, all's good
[17:51] <hatch> alright
[17:51] <bcsaller_> hatch: no :)
[17:51]  * hatch goes back to his cave :)
[17:51] <gary_poster> heh
[17:52] <bcsaller_> gary_poster: I've updated the tests to check that the charms are loading, and those are passing, not sure how much of that I changed since the last push, but I'll verify what you're seeing
[17:52] <gary_poster> ok cool
[17:53] <bcsaller_> ha, well, the initial demo is cool anyway ;)
[17:54] <gary_poster> :-) only small bugs bcsaller_ , no biggie
[18:00] <benji> gary_poster: (back from lunch) I can't say I specifically remember running the tests, but I would hope I did.
[18:02] <gary_poster> heh
[18:04] <gary_poster> benji, looks like it was bad and it may be worse: just got a report that the charm is now broken, possibly after teknico's commit.  Could you join me on guichat and we can work together for a bit?  This is an emergency (and our process surrounding the charm is a big lose, obviously :-( )
[18:05] <benji> gary_poster: sure, be right there
[18:05] <gary_poster> thx
[18:23] <hatch> gary_poster: whenever you have a moment if you could QA and review https://codereview.appspot.com/9132043/  that would be awesome :)
[18:23] <hatch> sorry it's a rather large diff
[18:24] <hatch> well....lots of files
[18:24] <hatch> oh poo
[18:25] <hatch> for some reason it didn't diff against the most recen't trunk
[18:25] <hatch> ill try again
[18:25] <gary_poster> hatch ok ping when ready
[18:29] <hatch> gary_poster: ok it's done
[18:33] <rick_h_> hatch: jcsackett or sinzui can I get some +1s on a 1 line change that took a day to figure out please? https://codereview.appspot.com/9101043
[18:33] <rick_h_> oops
[18:33] <rick_h_> well I guess it still works
[18:33] <hatch> woah woah woah....false advertising
[18:33] <hatch> that's clearly a 6line change
[18:34] <rick_h_> comments don't count :P
[18:34] <hatch> haha
[18:34] <rick_h_> I should get bonus points for avoiding explitives in my comments :)
[18:34] <hatch> I don't think the description matches the fix though?
[18:35] <sinzui> rick_h_, Thank you for the explanation for the zaniness
[18:35] <rick_h_> ? querysting listed before juju-gui in the use() block?
[18:35] <rick_h_> hatch: how so?
[18:36] <hatch> maybe I'm missunderstanding them "it looks like perhaps there is some extra render going on..."
[18:36] <hatch> should the description not reflect the fix?
[18:37] <rick_h_> hatch: ah, right forget that
[18:37] <rick_h_> that was the "oops'
[18:37] <hatch> ohhh
[18:37] <rick_h_> I had taken a first stab at the fix the other day
[18:37] <rick_h_> and used the same branch name on accident
[18:37] <hatch> ahhh
[18:37] <hatch> ok lgtm'd
[18:38] <rick_h_> thanks
[18:39] <sinzui> rick_h_, I added my LGTM. I think you are free to land
[18:39] <rick_h_> sinzui: thanks
[18:48] <benji> gary_poster: I'm getting test failures, but I think they are a local problem:
[18:48] <benji> WebDriverException: Message: 'Can\'t load the profile. Profile Dir: /tmp/tmpR9aoJc Firefox output: Xlib:  extension "RANDR" missing on display ":1015".\n*** LOG addons.xpi: startup\n*** LOG addons.xpi: checkForChanges\n*** LOG addons.xpi: No changes found\n'
[18:49] <gary_poster> benji http://jujugui.wordpress.com/2013/04/27/rarings-selenium-doesnt-like-rarings-firefox-my-solution/
[18:49] <bac> bcsaller_: i've got to go figure out how i've broken CI.  i'm not going to be able to review your branch very soon.  you may want to scare up someone else.  sorry.
[18:50] <bcsaller_> bac: np, thank you
[18:50]  * benji looks.
[18:51] <jcsackett> hatch: can i get you to look at https://codereview.appspot.com/9131043/
[18:51] <jcsackett> dammit.
[18:52] <jcsackett> buffer error, that's ricks.
[18:52] <jcsackett> or never mind, those are just *very* similar IDs.
[18:52] <rick_h_> jcsackett: yea, that's the one I reviewed so all good
[18:53] <jcsackett> rick_h_: yeah. hatch, can you give it the other look?
[18:53] <hatch> yu[
[18:53] <hatch> on it now
[18:54] <rick_h_> man I <3 usb3
[18:54] <rick_h_> "i'd like to backup ~ ... ok good"
[18:57] <hatch> gary_poster: for some reason it's picking up that test_model_controller.js is  anew file when in fact it's in trunk but I merged it in from it's branch before it was landed...so you can disregard that one if you like
[18:58] <gary_poster> ok
[19:05] <hatch> benji: you're reviewing bcsaller_'s branch?
[19:06] <benji> hatch: nope, but I can if need-be
[19:06] <hatch> oh no I ust saw you say 'looks'
[19:06] <hatch> I can do it if one is still needed
[19:07] <benji> hatch: have at it
[19:07] <hatch> bcsaller_: what's the link?
[19:07] <bcsaller_> https://codereview.appspot.com/9070043/
[19:07] <bcsaller_> and thanks
[19:08] <hatch> holy poo that's a large diff
[19:08] <hatch> :P
[19:08] <bcsaller_> its not actually that big, mostly new charm data for the tests I think
[19:08] <bcsaller_> and you'll get to see what all that charm/promise talk was about
[19:08] <gary_poster> hatch, your code is good but your diff is bad: A fix for /:gui:/ will come in a later branch?
[19:09] <benji> gary_poster: I'm getting this error after doing the virtualenv thing, does it ring any bells?
[19:09] <hatch> oh wow it's a lot worse than I thought...
[19:09] <benji> Traceback (most recent call last):
[19:09] <benji>   File "./deploy.test", line 9, in <module>
[19:09] <benji>     from selenium.webdriver import Firefox
[19:10] <hatch> gary_poster: any thoughts on how to fix this diff?
[19:10] <hatch> it's like it's not diffing from trunk
[19:11] <hatch> info shows that it's parent is /trunk though
[19:11] <gary_poster> hatch, in your shoes I'd re branch master, merge your existing branch, and repropose from that.  That's lazy but I don't have tim eto figure anything else out atm :-)
[19:12] <hatch> so branch trunk, merge my branch into that?
[19:12] <hatch> I can try that
[19:12] <gary_poster> hatch y
[19:12] <gary_poster> benji, no.
[19:12] <gary_poster> benji more info from reporter
[19:12] <benji> hmm
[19:12] <benji> <eyebrows raised>
[19:13] <gary_poster> benji, you saw on #webops?
[19:13] <benji> nope, looking now
[19:13] <benji> gary_poster: I'm not in #webops
[19:13] <gary_poster> benji, oh because of eyebrows I thought maybe so
[19:14] <gary_poster> benji:
 gary_poster: https://pastebin.canonical.com/90418/ to prepare the charm, then https://pastebin.canonical.com/90419/ as the config
[19:14] <benji> my eyebrows are easily misunderstood
[19:15] <gary_poster> :-)
[19:15] <gary_poster> benji, he's doing something weird.  I'll handle it. :-)  you see if you can wrap up something on your other work
[19:16] <benji> gary_poster: ok.  do you want me to abandon trying to run the jitsu tests for the charm?
[19:18] <gary_poster> benji, um.  up to you.  We must be able to run tests.  So that needs to be done.  OTOH, if you might have something actionable from your memory work in the remaining time it would be great to do that too.
[19:18] <benji> ok,  I don't know what the odds of actionable results are, but keeping doing what I was doing seems like the best route
[19:19] <hatch> gary_poster: ok this diff is much better https://codereview.appspot.com/9119044/ I can apply your changes to this branch so you don't have to do another review/qa
[19:19] <gary_poster> cool hatch, apply the changes then ping me and I will look
[19:19] <gary_poster> benji ack, go for it
[19:23] <hatch> sounds good
[19:42] <hatch> bcsaller_: review done
[19:46] <bcsaller_> hatch: thanks
[19:46] <gary_poster> hatch are changes applied or should I go to next call?
[19:47] <hatch> gary_poster: continue on - I just started after doing ben's review
[19:47] <gary_poster> cool hatch thx
[20:01] <hatch> gary_poster: changes are made and pushed to https://codereview.appspot.com/9119044/ I'm going to take lunch now
[20:03] <Makyo> Got a confirmation that I'll be working from a local co-working place tomorrow in the AM.  During the final few minutes of our meeting time , so I'll try to get there early.
[20:04] <Makyo> At least one other Canonical-er there, figure it's worth a try.
[20:04] <Makyo> Three, looks like.
[20:13] <hatch> Id have a 20minute drive to get to a co-working place here....not gona happen
[20:13] <hatch> :D
[20:14] <hatch> bac: did you see that your latest commit failed CI? Was that one from before the IE fixes?
[20:15] <bac> hatch: there are no ie fixes yet
[20:15] <hatch> ahh ok cool
[20:15] <bac> so it is expected
[20:32] <gary_poster> hatch looking now.  what's the story for :gui:/ environment registration: follow-on branch?  apologies if you already responded, but I didn't see it
[20:35] <gary_poster> nm hatch I see in code :-)
[20:35] <hatch> alright :)
[20:41] <jcsackett> rick_h_: you still around?
[20:41] <rick_h_> jcsackett: kinda, what's up?
[20:42] <jcsackett> i was an idiot and submitted that filter-string fix branch, which is blocked on aaron's code. i have a branch that reverts it, but my lxc won't load, which means i can't propose/submit.
[20:43] <jcsackett> was wondering if i could get you to help me get it through.
[20:43] <jcsackett> but if you're EoDing, perhaps hatch can help.
[20:43] <rick_h_> jcsackett: so, I'd ask if abentley's branch is going to land tomorrow. It landing isn't an issue atm since the browser is 'feature flag'd' behind the urls
[20:43] <jcsackett> rick_h_: ah, there is that.
[20:43] <rick_h_> jcsackett: the issue is only that searches will fail with categories due to upstream
[20:43] <rick_h_> nothing really 'breaks'
[20:44] <rick_h_> we just have to watch for the demo and if abentley will have a migration/final update to manage. tomorrow then all is good
[20:44] <rick_h_> jcsackett: but if you'd like to revert, shoot me the revert branch and I'll put it down and lbox it up
[20:44] <jcsackett> rick_h_: given what you've very sensibly pointed out, it's not a rush.
[20:45] <jcsackett> if aaron can't land his changes tomorrow, i'll land the revert then.
[20:45] <abentley> rick_h_, jcsackett: The charmworld change is nearly done.  Then I have to do the charm change, which should be fast.
[20:45] <rick_h_> jcsackett: rgr
[20:45] <rick_h_> abentley: awesome, good to hear.
[20:45] <jcsackett> abentley: you're a hero. :-)
[20:45]  * jcsackett totally forgot abentley was in this channel. :-P
[20:46] <jcsackett> rick_h_: have a nice evening, and good luck with raring upgrade tomorrow. my LXC woes are part of my upgrade. :-P
[20:46] <rick_h_> jcsackett: was just about to reboot to my usb device when you ping'd. Why I said I was 'kinda' around :)
[20:46] <jcsackett> rick_h_: i will delay you no more. :-)
[20:47] <rick_h_> jcsackett: good news is I've not lxc'd on this to date so hopefully avoid some of that
[20:47] <rick_h_> but definitely hoping to lxc/local juju it up on the new desktop when I get back
[20:47] <rick_h_> so :/
[20:47] <jcsackett> i think it's upgrade borked my setup. if you don't have a setup yet, maybe no problems.
[20:48] <rick_h_> jcsackett: yea, I'm a reinstall fan myself. backed up to NAS, external portable usb3, and boom goes the OS
[20:48] <jcsackett> rick_h_: yeah, i'm worried i'll need to reinstall now. but i'll spend some time seeing if i can figure out what's broken.
[20:56]  * Makyo -> dogwalk
[21:02] <gary_poster> hatch trying to qa. two conflicts with trunk; resolution is not entirely trivial. I'll share.
[21:02] <hatch> that's interesting - I merged it into trunk to get that diff and didn't get a conflict
[21:05] <gary_poster> hatch, new textarea integration code is conflict.  help me resolve this quickly on guichat?
[21:05] <hatch> ok sure thing
[21:20] <bac> gary_poster: CI "fix" is at https://codereview.appspot.com/9128044
[21:20] <bac> gary_poster: need any help with conflict?
[21:20] <gary_poster> bac, nah was pretty easy thank you
[21:21] <bac> gary_poster: cool.  ping me if you get to that review
[21:21] <gary_poster> bac review done
[21:27] <hatch> bac: lol "fix"
[21:30] <hatch> *sigh* back to the file watching errors
[21:31] <hatch> I thought those were behind me
[21:31] <hatch> :/
[21:31]  * Makyo back.
[21:32] <hatch> gary_poster: I can't reproduce the same bug - but when I try I get console errors....so that's almost better :)
[21:33] <hatch> oh
[21:33] <hatch> lol
[21:33] <hatch> gary_poster: did you var attachPlugins = function(view) { <----- pass the view into this function?
[21:34] <gary_poster> hazmat, one more move of that blueprint fwiw, to match rules: now https://blueprints.launchpad.net/juju-core/+spec/s-cloud-juju-role-based-access-control
[21:34] <hatch> I think we both missed that ;)
[21:34] <hazmat> gary_poster, thanks for the update
[21:34] <gary_poster> welcome
[21:34] <gary_poster> hatch, http://pastebin.ubuntu.com/5627317/ I think it is right
[21:35] <hatch> oh yeah - when I do that it works fine
[21:35] <hatch> heh
[21:35]  * hatch closes bug - unable to reproduce
[21:35] <gary_poster> ok
[21:35] <hatch> I'll try in chrome ubuntu
[21:36] <hatch> hmm
[21:36] <gary_poster> back later
[21:36] <hatch> gary_poster: yeah I can't reproduce...I am wondering if it's a race condition
[22:00] <hatch> wth same jenkins error?
[22:02] <hatch> investigating
[22:06] <hatch> fixed image id and set another build
[22:08] <hatch> we'll need to keep an eye on CI error messages - if we notice the image id error any more we might need to create our own image so that it's not changed.
[22:08] <hatch> bcsaller_: thanks for the review
[22:08] <bcsaller_> np
[22:11] <hatch> bcsaller_: mind doing me a favour and building this branch and then visiting a url? https://code.launchpad.net/~hatch/juju-gui/promise-conflict
[22:12] <hatch> the url is /:gui:/unit/mysql-5/  and it should dump you to the service view with 3x notifications
[22:13] <hatch> gary gets a loading screen and it works fine for me on all my devices
[22:14] <hatch> so I'm wondering if it's a race condition that I'm not seeing
[22:14] <bcsaller_> hatch: doing it now
[22:14] <hatch> thanks
[22:17] <hatch> yay CI passed IE tests again
[22:19] <bcsaller_> hatch:  I fired up improv while the server was running and it connected and then bounced to the service view. After that I re-entered the url, pressed enter, got the three notifications and sit on the loading screen, it might depend on if the 1st delta has happened or not at the time of the view resolution
[22:19] <hatch> hmm
[22:19] <hatch> well I definitely can't land it as it is
[22:20] <bcsaller_> because the db will be empty initially
[22:20] <hatch> ahhh I think I know why
[22:20] <hatch> even though we have promises we are still relying on the db change event
[22:20] <hatch> to re-fire them
[22:20] <hatch> poop
[22:22] <bcsaller_> async promise resolution + url management does sound error prone, unless the ui model is to block with a spinner waiting on the promises
[22:22] <hatch> are you able to reproduce it reliably?
[22:24] <hatch> I am wondering if removing the { update: true } from line 600 in app.js will be enough to fix it
[22:25] <hatch> I am hoping that that will cause a full re-render fixing the problem
[22:26] <bcsaller_> this time it gave me three notifications and then the proper service view, so it is a racce
[22:27] <hatch> thoughts on what to do?
[22:28] <hatch> wait something is really wrong here
[22:28] <hatch> ohh
[22:29] <hatch> maybe adding options.model = db.services.getById(req.params.id) on line 590 before the showview will fix
[22:29] <hatch> either that or removing the { update: true } on 600
[22:31] <hatch> ok I was finally able to reproduce the error
[22:38] <hatch> oh bac is gona be mad....the autosize widget tests fail in FF now
[22:42] <hatch> bcsaller_: whenever you get a moment if you could pull down the latest changes in the promise-conflict branch and see if you can get the error or if my hack has resolved it
[22:42] <bcsaller_> hatch: I was still poking at it so I can do it now
[22:42] <hatch> oh ok great
[22:44] <bcsaller_> hatch: I still get three error notifications, but it seems to redirect to the service page after 3 sucessful tries
[22:44] <hatch> yeah the error notifications will happen until we don't dispatch 3 times on load
[22:45] <hatch> so right now I'm hoping this fixes the race condition
[22:46] <hatch> I reloaded about 20x tmes and couldn't get the loading screen hang with this fix
[22:47] <bcsaller_> yeah, seems better to me as well
[22:48] <hatch> excellent
[22:48] <hatch> that's a relief
[22:48] <bcsaller_> the notifications might be excessive though :)
[22:48] <bcsaller_> hatch: maybe another timeout to spawn that?
[22:49] <hatch> hey....they are the ones trying to access an invalid unit/service :P
[22:49] <hatch> but yeah I suppose that's a reasonable workaround :)


[03:08] <blahdeblah> Anyone know how I can get some eyes on https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/2054688?  Did I submit it against the wrong package?
[03:08] -ubottu:#ubuntu-server- Launchpad bug 2054688 in linux-aws (Ubuntu) "Update ena to 2.10.x or later" [Undecided, New]
[03:12] <JanC> you might want to ask in #ubuntu-kernel also
[03:21] <blahdeblah> JanC: thanks
[19:17] <zph1nx> im having problems providing an rc.local script via cloud-init on an ubuntu 20.04.6 installation, for some reason the file does not show up in the finished install https://pastebin.com/QwE9NQ4z
[19:19] <dbungert> zph1nx: so late-commands runs at install time, and write_files isn't a subiquity command
[19:20] <dbungert> if you add a autoinstall.user-data section you can write standard cloud-config that runs at first boot
[19:20] <dbungert> that should be nested under autoinstall.user-data
[19:20] <dbungert> https://canonical-subiquity.readthedocs-hosted.com/en/latest/intro-to-autoinstall.html#cloud-init-and-autoinstall-interaction has what I hope are helpful clarifications here
[19:22] <zph1nx> dbungert: this is what this is, its a user-data cloud-init file that runs out of nocloud/ on the iso, its intended to be a zero touch installation, and the script im trying to add will pull from a webserver for additional bootstrapping
[19:25] <dbungert> zph1nx: right, but you have an autoinstall.write_files directive and that isn't a supported directive, nobody looks at that
[19:26] <dbungert> so either it needs to be moved up a level so that the files is written at install time, or down to autoinstall.user-data.write_files so that it is written at first boot
[19:32] <zph1nx> i added user-data: at the end of the file, and the write_files: block under that, would that work?
[19:35] <dbungert> zph1nx: I think that's the right direction.  you probably also want to do your chmod as part of write files with the permissions setting
[19:36] <dbungert> https://cloudinit.readthedocs.io/en/latest/reference/modules.html#write-files
[19:38] <zph1nx> ill try, just want to check if the file even ends up on the installed system before i chmod it now
[20:01] <wingarmac> Hi, I wonder if I could use 2 display adapters: 1. for tty (ssh -X afterwards) on CTRL+ALT+F1 display adapter 1 and another for Cinnamon on CTRL+ALT+F2 display adapter 2, while both remain displaying there respective content?
[20:03] <wingarmac> I think I must set this into /etc/lightdm/lightdm.conf after the creation for a con. file for each display adapter into /etc/X11/xorg.conf.d/
[20:03] <wingarmac> Can someone assist? I use ubuntu 22.04 server on the remote host I want to have on my second screen.
[20:10] <patdk-lap> hmm?
[20:11] <patdk-lap> open xterm, set fullscreen on the second monitor, ssh into server
[20:11] <patdk-lap> oh, you want to change that, you need to adjust your tty's
[20:13] <patdk-lap> you need to adjust systemctl<EMAIL_ADDRESS>I think
[20:13] <patdk-lap> cause tt1 would be your first one


[04:30] <mup> Bug #1488245 changed: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <lxc> <juju-core:Expired> <https://launchpad.net/bugs/1488245>


[00:07] <wxl> AlanD: an example possibility is the registry is corrupted. there are tools you can use to fix this within Ubuntu, but you kind of need to know what you're doing. Trinity Rescue Disk has a lot of these features in it.


[00:26] <elky_work> datacrusher: can we help?
[00:29] <elky_work> datacrusher: while you pretend to not be there despite the fact that you have only been idle for a few minutes, you might want to refer to the topic of this channel. "/topic" will generally show that if you are unable to see it at this moment.
[00:34]  * mneptok watches the last grains fall through the hourglass
[00:34]  * jrib banned datacrusher because he has ignored the !away factoid
[00:34] <datacrusher> [elky_work]: oh sorry
[00:35] <datacrusher> iv just disabled. i dont use to have scripts, this one gots me by the foot
[00:36] <Jack_Sparrow> datacrusher Why did you rejoin?
[00:36] <Jack_Sparrow> k
[00:47] <elky_work> im guessing the ban was not revoked
[00:47] <elky_work> i'm not in whichever channel at the moment
[00:55] <tuxice> hello/
[00:55] <tuxice> ?
[00:55] <Jack_Sparrow> tuxice How may we help you today
[00:56] <tuxice> hello Jack_Sparrow i was wondering what are the requirements for a bot to join #ubuntu-bots?
[00:56] <Jack_Sparrow> no idea, why do you want to run a bot in there?
[00:57] <tuxice> i think a bot i have programmed is a good bot for experimenting with.
[00:57] <tuxice> it is based on supybot much like ubottu
[00:58] <Jack_Sparrow> tuxice I would think it would not be appropriate for you to have your experimental bot in a ubuntu chanel
[00:58] <tuxice> ah but it is completly stable
[00:58] <tuxice> but ok.
[00:58] <Jack_Sparrow> I will be up to someone else..  try again when there are more ops around
[00:59] <Jack_Sparrow> it
[00:59] <tuxice> Ok.
[00:59] <tuxice> Thank You for your time.
[00:59] <Jack_Sparrow> np
[01:50] <J_Smirnoff> Who are ops in +1
[01:51] <Pici> Was that necessary?
[01:51] <J_Smirnoff> Yea, I am pissewd
[01:51] <J_Smirnoff> that piece of shit generic in +1 needs a bitch slap
[01:53] <Pici> J_Smirnoff: I think you need to take a break
[01:54] <Jack_Sparrow> He mouths off to me in ubuntu and in pm and continued in +1
[01:57] <Pici> I understand the use of ! ops in a channel where you may not have priveleges, but it wasn't apparent in that command or your question here as to what it was pertaining to.
[01:58] <Jack_Sparrow> I have hobbsee in pm
[02:10] <Jack_Sparrow> pici              is    /msg ubottu @btlogin   not working?
[02:11] <Pici> Try @login first
[02:11] <Jack_Sparrow> nope
[02:16] <Jack_Sparrow> Pici since I cant make a note on the page, I wanted to say I dont intend to lift the ban on generic any time soon.
[04:37] <elky_work> ubottu: <reply> The Edubuntu Handbook is currently a work-in-progress and can be browsed via http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/
[13:04] <PriceChild> this channel is publically logged and it is important that we murt be accountable. it is also a good idea not to use access in situations where we maw be (emotionally) biased
[13:05] <Mez> s/murt/must/
[13:05] <bazhang> maw!
[13:05] <Mez> s/maw/may
[13:06] <Mez> /
[13:06] <bazhang> paw!
[13:07] <PriceChild> I also understand certain situations will really get on nerves, but please be very careful when venting
[13:07] <Mez> PriceChild, whats this about?
[13:08] <bazhang> okay PriceChild
[13:08] <bazhang> sorry
[13:08] <PriceChild> Mez: a general reminder
[13:08]  * Mez hugs PriceChild
[13:08] <PriceChild> bazhang: uu have you done something wrong i should review? ;)
[13:08] <bazhang> ruh roh
[13:08]  * bazhang hides
[13:10] <Mez> oh... foo
[13:10] <Mez> Yarr...
[13:12] <Pricey> All personal attacks and insults should be left in private if they must be made.
[13:13] <Pricey> Well..
[13:13] <Pici> I disagree.
[13:13] <Pricey> That doesn't read how i meant
[13:14] <elky> there's nothing wrong with private venting. venting privately at people is not quite what he meant though.
[13:14] <Pricey> If you want to vent, particularly with colourful language, probably best not here
[13:14] <elky> even that doesnt make sense
[13:14]  * Mez staples a copy o' th' Code o' Conduct t' Pricey
[13:14] <Pricey> Send it to my pm
[13:14] <bazhang> better to do with PM ubottu
[13:14] <Pici> And not at the person that's causing you to lose your cool either.
[13:14] <bazhang> righto Pici
[13:15] <Pricey> Personal attacks and insults are a no no in general and i don't want to see them.
[13:15] <Mez> Pricey, It seems t' me that thar`s been some issue that`s made ye say this... Somethin' we ortin' ta know about?
[13:15] <Pricey> Sure, if there are issues between people we can be constructive!
[13:22] <Pricey> Mez i just catch up on backlog around lunchtime, gentle reminder.
[13:23] <Mez> :P
[13:26] <elky> there's nothing in the CoC that says we have to bottle up, or that we have to bite our lip and be super-generous in regards to everyone else's idiocy.  Nal? :P
[13:29] <elky> even nal
[13:30] <Pricey> :O
[15:04] <jpds> Hey everyone.
[15:04] <Pici> Hi
[15:04] <bazhang> hi jpds
[15:08] <jpds> What have I missed?
[15:09] <jussi01> everything... :P
[15:09] <jussi01> hei all!
[16:32] <ikonia> anyone else getting pm spam from jignesh asking for your mail address
[16:33] <Jack_Sparrow> just you and in channel too
[16:33] <bazhang> no, but he asked for yours in channel ikonia
[16:33] <ikonia> ooh, I didn't see that
[16:33] <bazhang> he has left #ubuntu though
[16:33] <ikonia> he' pm'ing the heck out of me
[16:34] <jpds>  /ignore
[16:34] <ikonia> I missed him asking in #ubuntu
[16:34] <bazhang> yuck
[16:34] <ikonia> jpds: he'll go it's fine
[16:34] <ikonia> didn't realise he's asked in channel, that makes sense now
[16:34] <bazhang> likely someone you helped out long ago :)
[16:35] <Pici> They remember you.. even if you don't remember them
[16:35] <bazhang> ooh scary
[16:35] <ikonia> never heard the nick, no big deal
[16:35] <ikonia> it's not a pain, just wanted to make sure he wasn't hitting the channel
[16:35] <ikonia>  or others yusers
[16:49] <jussi01> Who is about? anyone?
[16:49] <bazhang> hi
[16:50] <jussi01> heya bazhang
[16:50] <bazhang> :)
[16:50] <ikonia> yes
[16:50] <Pici> hi
[16:51] <jussi01> ooh, we have life :D
[16:51] <bazhang> haha
[16:51] <bazhang> for relative definitions of such, yes
[16:51] <jussi01> I need an answer to a particularly complex question...
[16:51] <Pici> 42
[16:51] <bazhang> laden or unladen
[16:51] <jussi01> What shall I do with my friday night?
[16:52] <ikonia> party
[16:52] <jussi01> a)sit on IRC
[16:52] <bazhang> no!
[16:52] <jussi01> b) Party while Im away from my wife...
[16:52] <jussi01> c)something else...
[16:52] <ikonia> jussi01: correct answer
[16:52] <ikonia> b. b. b. b.
[16:52] <bazhang> d
[16:53] <jussi01> bazhang: d) is: go mad talking to you lot....
[16:53] <bazhang> jussi01, err b then :)
[16:54] <ikonia> jussi01: what are you in the mod for
[16:54] <Pici> jussi01: Dress up like a pirate
[16:54] <jussi01> rofl
[16:54] <bazhang> haha
[16:55] <Jack_Sparrow> Arrrgh, talk like a Pirate Fridays..
[16:55] <jussi01> Im not feeling real top of the world, but If I stay in Iwant to actually do something...
[16:55] <jussi01> (apart from ban annoying trolls...)
[16:55] <Tm_T> like me?
[16:56] <ikonia> jussi01 any jobs need doing, painting, building, coding, cleaning, etc
[16:56] <jussi01> yes, like you
[16:56] <ikonia> jussi01: put some music on and get productive
[16:56] <jussi01> ikonia: but what!!!!????
[16:57] <ikonia> jussi01: what tasks to you have pending
[16:58] <jussi01> ikonia: hrm... nothing!!! :D Im trying to relax...
[16:58] <ikonia> jussi01: read a good book
[16:58] <ikonia> get into it
[16:58] <jussi01> I need to dosomething helpful...
[16:58] <Pici> Watch episodes of House
[16:58] <bazhang> oof
[16:58] <jussi01> or perhaps I should just go practice guitar...
[16:59] <ikonia> jussi01: yes !
[16:59] <jussi01> Pici: hrm... maybe scrubs... :D
[16:59] <ikonia> jussi01: I'll be playing tonioght
[16:59] <Tm_T> jussi01: maybe I should teach you with guitar
[16:59] <jussi01> ikonia: nice.
[16:59] <ikonia> infact, I'm off to get my train
[17:01] <jussi01> hrm that reminds me, anyone know what is the status of the IRC council nomination/election stuff?
[17:02] <jussi01> PriceChild: ?
[17:02] <Pici> jussi01: He said he would look at it tonight.
[17:03] <jussi01> ok
[21:13] <jussi01> tuxice: How can we help you today?
[21:13] <tuxice> bot questions
[21:13] <tuxice> about #ubutnu-bots
[21:14] <tuxice> ive got a bot designed for experimenting by users, it is perfectly stable. Can i have it join #ubuntu-bots
[21:14] <jussi01> tuxice: no.
[21:14] <jussi01> #ubuntu-bots is for the ubuntu bots, ubottu ubot3` ubot5 bestbot etc
[21:15] <tuxice> ok
[21:15] <tuxice> just curious ;)
[21:15] <jussi01> :)
[21:15] <tuxice> ok thanks
[21:15] <jussi01> just out of curiosity, wht does your bot ddo?
[21:16] <jussi01> tuxice: ^^
[21:16] <tuxice> its much like ubottu, even based on supybot, its an information bot designed for giving factoids, moderating a channel and retrieving wikipedia articles and google search term URL's
[21:16] <jussi01> tuxice: ok.
[21:17] <tuxice> ok thanks for your time
[21:17] <jussi01> no probs.
[21:20] <linkdd> c'est ici ubuntu-troll ?
[21:41] <jussi01> ompaul: around?
[21:41] <ompaul> jussi01, only just
[21:41] <ompaul> bouncy isp
[21:41] <jussi01> ompaul: quick pm?
[21:41] <ompaul> I want to bouncy them off the ground
[21:41] <ompaul> jussi01, certainly
[22:17] <jussio1> !test
[22:17] <Pici> !test
[22:17] <jussio1> crap
[22:35] <PriceChild> jussio1: hmm... crap
[22:35] <ompaul> !test
[22:36] <PriceChild> Uuuu where's my button...
[22:36] <PriceChild> *looks*
[22:37]  * PriceChild presses
[22:37]  * PriceChild cheers
[22:42]  * jussi01 hugs PriceChild....
[22:42] <jussi01> PriceChild: which button was that?
[22:42] <PriceChild> jussi01: the secret one you gave me but warned me about.
[22:43] <jussi01> ahh
[22:43]  * jussi01 hugs ubottu
[23:18] <PriceChild> Hmm, watching #ubuntuforums-beginners, got some odd 'spam' in there about ##ubunteens, no need to join.
[23:20] <Jack_Sparrow> @btlogin


[00:07] <Azelphur> Sarvatt: awesome I'll get on your repo and let you know  :)
[00:08] <Sarvatt> Azelphur: thanks, the patch seems to address your exact problem even though the description leaves a lot to be desired :)
[00:08] <Azelphur> hehe
[00:39] <Sarvatt> http://www.spinics.net/lists/dri-devel/msg06034.html -- so THATS why it wasn't working with hdmi!
[02:25] <Sarvatt> I guess input-utils needs rebuilding pretty often now?
[02:25] <Sarvatt> sudo lsinput
[02:25] <Sarvatt> /dev/input/event0
[02:25] <Sarvatt> protocol version mismatch (expected 65536, got 65537)
[02:25] <Sarvatt> works when rebuilt
[02:44] <RAOF> Sarvatt: Yeah, roughly once per kernel rev.
[05:44] <DanaG> Say, how do you use synclient -m without SHMConfig?
[05:44] <DanaG> Can't access shared memory area. SHMConfig disabled?
[05:44] <DanaG> They say SHMConfig has been replaced by xinput... but xinput can't do -m.
[05:45] <DanaG> 3 lines in xorg log:  (--) Apple Wireless Trackpad: no supported touchpad found    (EE) Apple Wireless Trackpad Unable to query/initialize Synaptics hardware.   (EE) PreInit failed for input device "Apple Wireless Trackpad"
[05:45] <DanaG> I removed line breaks, of course.
[05:46] <DanaG> I do have shmconfig on... but it's ignoring it.
[05:46] <DanaG> shmget(0x5d8b, 96, 0)                   = -1 ENOENT (No such file or directory)       shmget(0x5d8b, 0, 0)                    = -1 ENOENT (No such file or directory)
[05:48] <DanaG> As far as I'm concerned, that's a regression.  They should've made the SHM area read-only and root-only.
[05:49] <DanaG> Maybe I should file a regression bug-report.
[05:49] <DanaG> odd, despite that error, edge-scrolling still works.
[05:51] <DanaG> Two-finger does not work, thanks to Gnome.  :(
[05:52] <DanaG> Can't do both together.
[06:48] <Sarvatt> RAOF: did you see your alt+tab bug was fixed? https://bugs.freedesktop.org/show_bug.cgi?id=32246
[06:48] <ubot4> Freedesktop bug 32246 in Drivers/DRI/R600 "Compiz 0.9 switcher segfaults in mipmap generation code" [Normal,New]
[06:48] <Sarvatt> new mesa uploading now
[08:14] <RAOF> Sarvatt: Awesomesauce.
[08:14] <RAOF> I'm surprised that's the fix, though.
[08:14]  * RAOF clearly doesn't (yet?) understand the mesa code.
[09:58] <hyperair> Sarvatt: all the compizes crash iwth latest mesa. what happened?
[09:58] <hyperair> http://paste.debian.net/101951/
[10:04] <Sarvatt> hyperair: what gpu again?
[10:06] <hyperair> 965
[10:06] <hyperair> 8086:2a02
[10:07] <Sarvatt> thanks, passed it along to anholt
[10:08] <hyperair> yeah i saw, thanks
[10:08]  * hyperair starts downgrading his mesa
[10:08] <RAOF> Aaah, constant buffers.
[10:09] <hyperair> there also seem to be some weird issues with fonts
[10:09] <hyperair> like weird font corruption that fixes itself a little later
[10:09] <Sarvatt> yeah they've been going back and forth on that one in #intel-gfx for the past few days
[10:09] <hyperair> ah
[10:11] <Sarvatt> oh wait, http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=9b967807c2d240488a715509649663aac3583532 isn't the in ppa
[10:11] <hyperair> Sarvatt: oh yeah everything's rendering smoothly but with significant latency, like half a sec late.
[10:11] <Sarvatt> new one uploaded
[10:11] <hyperair> weird
[10:12] <hyperair> ok
[10:13] <Sarvatt> i'll revert that mesa commit for now too
[10:14]  * Sarvatt has to be up for work in 3 hours, ha!
[10:14] <hyperair> lol
[16:55] <Azelphur> Sarvatt: your patch looks good, havn't had a crash yet.
[18:07] <Sarvatt> sent all the --no-add-needed patches to the xorg-devel list so they should hopefully stop needing Makefile.in patches in the next 5 years, hope I didn't miss any :)
[18:13] <Sarvatt> I fail at git send-email, didn't mean for them to be threaded
[18:27] <Sarvatt> ha, need to point people complaining about i915 wakeups at this thread http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2439?set_lines=100000
[18:28] <bryceh> lengthy thread
[18:29] <Sarvatt> tldr; showing seconds in the clock applet with compiz kills the battery
[18:30] <bryceh> yeah that's kind of funny (in a sad way)
[18:48] <bdmurray> I'm planning on consolidating some fglrx package bugs about build failures that contain "kcl_ioctl.c:196: error: implicit declaration of function ‘compat_alloc_user_space’
[18:48] <bdmurray> in the DKMSBuildLog okay?
[18:50] <bdmurray> bryceh: ^
[18:50] <Sarvatt> bdmurray: what release are they using?
[18:51] <Sarvatt> afaik the fix is released to all releases back to lucid
[18:51] <Sarvatt> they just need to enable -updates
[18:51] <bdmurray> Hmm, I see the following 8.771 8.723.1 8.780 - could check releases in a minute
[18:52]  * Sarvatt double checks
[18:52] <Sarvatt> bdmurray: ah I see the problem
[18:52] <Sarvatt> only natty has it fixed for 2.6.37 kernels
[18:53] <Sarvatt> the dkms patches were limited to 2.6.36 in the previous fix
[18:53] <bdmurray> Sarvatt: okay, but its all the same bug?
[18:53] <Sarvatt> yep, lucid and maverick fglrx needs an update to work with 2.6.37+
[18:53] <bryceh> bdmurray, merging fglrx bug reports sounds good
[18:54] <Sarvatt> tseliot didn't like me fixing natty so should assign it to him :)
[18:54] <bdmurray> now, I'm not gonna get involved in personal issues like that ;-)
[18:56] <Sarvatt> bdmurray: really though, it's because he maintain the packaging in git that the OEM's pull from to make releases so he's got to fix it
[18:57] <Sarvatt> it's a really simple fix, the regex matches in debian/dkms.conf.in need updating to not only apply to 2.6.36
[18:57] <bdmurray> Sarvatt: actually shouldn't these be a dup of the one you fixed?
[18:57] <Sarvatt> good point, I don't have permission to open lucid and maverick tasks for it though
[18:58] <bdmurray> Sarvatt: I can help with that if you tell me the bug number. ;-)
[18:58] <Sarvatt> bug #671868
[18:58] <ubot4> Launchpad bug 671868 in fglrx-installer (Ubuntu) "package fglrx 2:8.780-0ubuntu2 failed to install/upgrade: fglrx kernel module failed to build (affects: 1) (heat: 109)" [High,Fix released] https://launchpad.net/bugs/671868
[19:05] <Sarvatt> pain in the butt having to dig in the logs of all of these bugs though, failed to install/upgrade: fglrx kernel module failed to build is usually also a header package problem
[19:11] <bdmurray> Sarvatt: if you tell me what to look for in the logs its not hard for me
[19:20] <Sarvatt> bdmurray: go figure all of the ones I've looked at so far need eyes on them, most were people installing fglrx manually and things were in an inconsistent state
[19:21] <bdmurray> ah that sucks
[20:21] <bdmurray> Sarvatt: what about build failures due to not matching the current kernel?
[20:22] <Sarvatt> *usually* it happens because they have -generic metapackages installed but a generic-pae kernel and there is no way to make fglrx require the correct type of headers
[20:22] <Sarvatt> (same problem with any dkms package there)
[20:44] <RAOF> Sarvatt: I thought that prospective fix for the mipmap crasher was odd, and indeed it doesn't fix it :)
[20:47] <Sarvatt> really? you had maxLevels = 15 in your backtrace and someone on #radeon mentioned bumping what he pushed fixed etuxracer aborting so had me hopeful
[20:50] <Sarvatt> this libsm libxt libxmu .pc thing looks like it'd fix hundreds of ftbs' if we reverted it, or am I misunderstanding?
[20:51] <Sarvatt> most of the failures i've come across are from things having xt in PKG_CHECK_MODULES and not picking up -lX11
[20:54] <RAOF> Let me see...
[20:55] <Sarvatt> we're removing x11 from Requires: in the .pc for xt and xmu/xmuu, and ice from sm
[20:55] <Sarvatt> so -lX11/-lICE gets dropped
[20:56] <RAOF> That might not actually be the correct solution, though.
[20:56] <Sarvatt> I wish this --no-add-needed crap waited until after squeeze released so we didn't have hundreds of modified packages
[21:01] <RAOF> Hm.  It looks like Xmu should at least have a requirement on Xt; it's headers call Xt functions in #defines.
[21:11] <RAOF> Man, I'm glad that Xmu is able to handle systems with 6-bit bytes.
[21:13] <jcristau> Sarvatt: i'd be ok with reverting these changes fwiw
[21:14] <jcristau> a bit sad, but meh.
[21:18] <RAOF> As I mentioned above, I think the dropping of the Xt requires is wrong; the headers have #defines which use Xt symbols.  The other drops still look correct.
[21:18] <jcristau> ok
[21:21] <RAOF> Can I commit that to debian-unstable?
[21:23] <RAOF> Hm.  Why does libxmmu not ship any headers at all?
[21:24] <RAOF> Bah.  Because dependency chain.
[21:25] <jcristau> headers are in libxmu-headers iirc
[21:25] <RAOF> Yeah, found that.
[21:30] <Sarvatt> looks like xless is the only one that'll be fixed by that so far
[21:30] <RAOF> Possibly Xt needs an X11 requires? :)
[21:31] <RAOF> Alternatively, a lot of build systems have wrong dependencies.
[21:32] <jcristau> also something we're patching out..
[21:32] <RAOF> Yeah, I'm checking Xt now
[21:32] <Sarvatt> most things fail at x11 before hitting the xt failure so it probably fixes part of lots more
[21:33] <jcristau> Xt without Xlib doesn't really make sense, so would probably not hurt to put it back
[21:33] <jcristau> dunno about sm
[21:34] <Sarvatt> 136 ftbs with  libX11.so.6: could not read symbols: Invalid operation
[21:35] <Sarvatt> hmm those are --as-needed failures aren't they
[21:35] <Sarvatt> --no-add-needed shows up with the undefinied reference errors on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[21:37] <RAOF> Yup, there we go.  Xt uses XMapWindow in a #define in one of its public headers, hence needs -lX11
[21:40] <RAOF> And now, for libsm
[21:41] <jcristau> libSM seems only used for a SmcConn member in Xt's SessionShellPart
[21:42] <RAOF> Oh, I was only looking for X11 references in Xt!
[21:48] <RAOF> And libSM doesn't use any libICE symbols in it's headers; the dropped Requires is correct.
[21:51] <RAOF> jcristau: Are those Requires fixes acceptable for debian-unstable, or debian-experimental, or shall we take an Ubuntu delta?
[21:52] <jcristau> -unstable works
[22:04] <Sarvatt> so the libSM .pc change should go upstream possible and then the smproxy ice addition to PKG_CHECK_MODULES is the only one that'd be needed out of the series I guess
[22:04] <Sarvatt> or we can just patch that :)
[23:34] <Sarvatt> RAOF: fixed as in it was only reported against earlier lucid and I haven't seen any other reports about it, I'm not completely sure
[23:35] <Sarvatt> bah, wrong channel sorry
[23:35] <RAOF> Sarvatt: I'm pretty sure it got fixed by not using the drm renderer on nouveau :)
[23:35] <Sarvatt> well it would fall back to that same behavior if we ditched the vesafb junk :)
[23:36] <RAOF> :)
[23:39] <Sarvatt> what it looks like to me currently is: vesafb loads, picks 640x480x8 or whatever, plymouth loads framebuffer renderer and starts using that, hands off to drmfb and gets resized up to native but plymouth is still drawing to the lower color framebuffer. that's all conjecture though
[23:40] <Sarvatt> will try forcing a different mode next time i reboot to see
[23:43] <RAOF> Good plan; I'll do the same.
[23:45] <Sarvatt> oh - [    1.673571] vesafb: mode is 640x480x32, linelength=2560, pages=0
[23:46] <Sarvatt> can't remember how to get the good logs out of plymouth I used to figure out what renderer backend it was using a long time ago..
[23:47] <Sarvatt> ah plymouth:debug and its in /var/log/