[13:20] <czajkowski> aloha
[13:24] <slashtom> hey, how are you?
[13:27] <czajkowski> knackered
[13:27] <czajkowski> good to see folks yesterday though
[20:56] <airurando> evening all
[21:39] <moylan> hi airurando
[21:40] <airurando> hey moylan
[21:40] <airurando> how was UHD?
[21:40] <moylan> you missed a great night last night.  but don't worry i saw tons of pics been taken.  they'll appear i reckon in the next few days.
[21:40] <airurando> cool
[21:40] <moylan> hows the hols going?
[21:41] <airurando> not hols as such
[21:41] <moylan> a break?
[21:41] <airurando> sister in laws wedding last sat.
[21:41]  * airurando was a groomsman
[21:42] <moylan> ah a family do.  can be great, can be ominous.
[21:42] <airurando> they down to Tralee to do a few jobs on our house there getting it fit for letting
[21:42] <airurando> the wedding was great
[21:43] <airurando> Jackie was one of the bridesmaids
[21:43] <moylan> it can be great to meet with family that you don't see from one year to the next.
[21:43] <airurando> matron of honour actually :)
[21:44] <moylan> hope you passed out a few ubuntu cds! :-D
[21:44] <airurando> I was delighted it went well for the couple
[21:44] <airurando> not quite
[21:44] <moylan> good weather?
[21:44] <airurando> great weather in Cork
[21:44] <SCD101> lol
[21:45] <airurando> regarding the CDs though
[21:45] <airurando> might be in the process of getting my sisters household over.
[21:46] <airurando> SCD101 sur the weather is always great in Cork
[21:46] <moylan> it's always good to get somebody off windows.  especially if you were supporting them when they were using windows!
[21:46] <SCD101> As it is in Dublin :P
[21:47] <airurando> SCD101 the only affiliation I have with Cork is that my fabilous wife is from the fine city and county.
[21:47] <SCD101> As it should be ;)
[21:48] <SCD101> Remove the population and slowly convert them
[21:48] <moylan> my family moved from cork to dun laoghaire around 1840s.  we're still considered blowins in dun laoghaire
[21:48]  * airurando was born in the combe
[21:48]  * SCD101 was also
[21:48] <airurando> *coombe
[21:48] <airurando> my grandparents retired to Glasnevin
[21:49] <airurando> on my fathers side
[21:49] <airurando> moylan: will you blog about UHD?
[21:50] <moylan> i'll try and put together a few lines.  if i don't sleep tonight i'll start work on it.
[21:51] <airurando> good stuff
[21:52] <airurando> It was a shame I could not get there
[21:52] <moylan> the _one_ time you are not there!
[21:53] <airurando> indeed :(
[21:55] <moylan> not only was it because czajkowski was over but i reckon that there hadn't been one for a few months may have helped.
[21:56] <airurando> yeah
[21:56] <airurando> how many were there?
[21:57] <moylan> 7-8
[21:57] <moylan> actually 9
[21:58] <airurando> nice
[21:59] <moylan> i also wonder if doing it on a wednesday helped
[22:00] <airurando> we always had it on a wednesday
[22:00] <airurando> last wednesday of the month
[22:00] <moylan> whoops.  sorry my brain is a bit wonky at the mo
[22:02] <airurando> still waiting on the first sat/sun one in a cafe/library.
[22:03]  * moylan mumbles embassingly
[22:03] <airurando> lol
[22:03] <airurando> hope you pick a saturday that I'm not working
[22:04] <moylan> have to pick a saturday that doesn't clash with my rpg group.  it's been moved around at the mo.
[22:05] <airurando> excuse the ignorance
[22:05] <airurando> whats rpg?
[22:06] <moylan> role playing game.  in this an old fashioned dice and figures game with thick thick books.
[22:06] <moylan> this case an


[09:17] <niemeyer> Mornings
[09:18] <Chipaca> good morning!
[09:24] <Chipaca> jam: WRT create_harness returning one arg or two, I think it being two does signal the divide very cearly, but OTOH it feels very un-pythonic and very go-ish
[09:28] <Chipaca> I wonder what Facu thinks about two-vs-one, maybe it's not as unpythonic as i think
[09:29] <niemeyer> The main question I'd ask in this context is whether people will use both almost always
[09:29] <niemeyer> If that's true, then returning both seems fine.. if it's not true, then it's a bit awkward
[09:31] <niemeyer> The create_harness name also leans itself to a single argument a bit better
[09:32] <niemeyer> Another advantage of the single argument is that as the harness is passed around, the many test methods will have the charm at hand as well
[10:30] <Chipaca> hm, mark maglana makes a fair point
[10:30] <Chipaca> bah, more or less
[10:30] <Chipaca> hm
[10:44] <jam> Chipaca: well for me, integration tests would be the next level up, where you are interacting with other charms.
[10:44] <jam> I don't see a way to "just do unit tests" of MyCharm.on_install without having the harness
[10:44] <jam> since the whole point is that on_install is going to look at the model and figure out what it needs to do.
[10:44] <Chipaca> that's the "more or less" thing: there isn't One True Definition of where the line between unit and integration and functional and … is
[10:46] <Chipaca> jam: i'll answer on the pr
[10:52] <Chipaca> hopefully that communicated the nuances
[11:00] <jam> thx
[11:00] <jam> https://github.com/canonical/operator/pull/181 is some docs for charm.py. It turns out I didn't want to make anything private.
[11:01] <Chipaca> jam: yeah from that ginormous list i grepped there wasn't anything that stood out as private, to my eyes
[11:02] <Chipaca> WRT #160, do we want ops to be a namespace or not?
[11:02] <Chipaca> we could always have a separate namespace package that's only used for that
[11:02] <Chipaca> might make things easier
[11:02] <Chipaca> e.g. have ops-helpers
[11:03] <Chipaca> ops_helpers*
[11:04] <Chipaca> then we'd have ops_helpers-apt as a repo/pypi entry, with ops_helpers.apt in it, etc., getting the independent component aspect of the namespaced without the worry about random people polluting ops itself
[11:10] <jam> unfortunately this falls very much into "until we use it in anger, we won't really know how one vs the other feels"
[11:11] <jam> ops.helpers is a bit nicer, IMO, but requires ops to be a namespace first.
[11:12] <jam> Chipaca: so LazyMapping is one that I would consider making private, as it is an implementation detail. same for BindingMapping and *maybe* RelationMapping, though the last one is exposed as an attribute from Model.relations
[11:13] <jam> the other 2 are not directly exposed.
[11:14] <jam> Handle is probably also something that is more of an implementation detail for events.
[11:14] <jam> It doesn't feel like something that we would want charmers to actively engage with.
[11:15] <jam> Chipaca: it is now quite hard for me to go through looking for private things and *not* docstring everything...
[11:16] <jam> StoredDict/List/Set also feel like they should be hidden details.
[11:16] <jam> Yes you have one of them, but you shouldn't be creating them.
[11:16] <Chipaca> just because it's exposed doesn't mean it has to be public, right?
[11:17] <Chipaca> i mean we could document it as a collections.abc.Mapping or something
[11:22] <Facu> Muy buenos días a todos!
[11:28] <Chipaca> Facu: ｇｏｏｏｏｏｄ  ｍｏｒｎｉｎｇ！
[11:28] <Facu> :)
[11:29] <Chipaca> hehe, i hadn't use that one in *ages*
[11:30] <Chipaca> niemeyer: when does your self-immolation^Wisolation end?
[11:38] <niemeyer> > that's the "more or less" thing: there isn't One True Definition of where the line between unit and integration and functional and … is
[11:39] <niemeyer> Yeah, I wouldn't get too worried about that either.. it's more about what we're testing and how than how people choose to label those tests
[11:39] <niemeyer> I haven't seen the issue yet, though, so let me read it to get more context
[11:39] <niemeyer> Chipaca: My current plan is to go back home on Saturday if nothing else happens
[11:39] <niemeyer> Like me starting to cough desperately..
[11:40] <Facu> https://github.com/canonical/operator/issues/179 talks about adding a `self.open_port` that IIUC a way to telling juju to do something; do we have others like that already implemented? example?
[11:41] <niemeyer> Hmm.. I don't see any issues related to functional testing
[11:41] <niemeyer> Facu: Yeah, we have quite a bit of them.. they're not all sticking to the same location, though.. depends a bit on context, which you'll heave to think through a bit
[11:41] <niemeyer> Facu: But basically,
[11:42] <niemeyer> Facu: We have a backend that deals with calling the actual commands.. so that's the only piece of code that should be doing that job. It's replaceable for testing. Then,
[11:42] <Facu> (I was trying to spot the part of the code that implements this kind of communication to juju)
[11:43] <niemeyer> Facu: The Model is the thing that represents the world view in that specific charm and unit.. through it the code can navigate through several aspects such as configuration, units, apps, etc
[11:43] <niemeyer> Facu: The backend method that calls the commands sticks on one of these places, trying as much as possible to relate to the specific type where the method is made available
[11:44] <niemeyer> Facu: With that knowledge, navigate for a while in the model code and you'll get a good grasp of all the pieces
[11:44] <Facu> niemeyer, for example, that open_port would be a method of model.Network?
[11:45] <niemeyer> Facu: Maybe, but maybe not depending on what that means
[11:46] <niemeyer> Facu: I'll need to dig down in the model to remember the exact relationships as well.. here is the thing to keep in mind: what is the job of open/close port?  What exact part of the model is being affected by it?
[11:46] <Facu> mmm... or maybe Unit
[11:46] <Facu> niemeyer, perfect, thanks
[11:46] <niemeyer> Facu: With that questioning, look through the existing model and try to picture it
[11:49] <Chipaca> niemeyer: wrt testing, comment at the bottom of the harness pr
[11:51] <niemeyer> Chipaca: Thanks.. yeah, not really worried about that point
[11:52] <niemeyer> If all people every do is use the harness to test their charm, that's still much better than doing absolutely nothing..
[11:52] <niemeyer> We won't be able to force people to write tests they don't want to, no matter how we name it
[11:52] <niemeyer> We can encourage them to write tests, though, by making it as easy as possible to do so
[11:54] <Chipaca> sigh. People that are convinced they follow the One True Way.
[11:54] <Chipaca> the one true way being, in this case, apparently, "mock all the things"
[11:54]  * Chipaca mocks the 'mock all the things' attitude
[11:55] <Chipaca> actually, i'm being mean. i should stop that.
[11:55] <niemeyer> Yeah, stop mocking them
[11:57] <jam> Chipaca: so my particular feeling on his charms is that he has written yet-another-framework. Which might be a framework we want to discuss (what would it look like if our events passed the context in and got it back out again). But if he is going to implement yet-another-adapter anyway
[11:57] <jam> I'm not sure there is much we could do on our end.
[11:57] <jam> I do understand having clear Interfaces for your code. But eventually the abstractions make it hard to know what is actually going on.
[11:57] <niemeyer> > what would it look like if our events passed the context in and got it back out again
[11:57] <jam> I personally find the test quite obtuse to actually see what it is setting up and testing.
[11:57] <niemeyer> What do you mean here?
[11:58] <jam> niemeyer: if the State and Model were passed as parameters instead of attributes of the Charm.
[11:58] <jam> eg, everything is just functional
[11:58] <jam> but IMO, that is a different framework.
[11:58] <niemeyer> Yeah, it's called Haskell
[12:00] <niemeyer> We want to be following good practices, but we don't want to do so just because it's dogmatic.. it's more relevant to make Python developers feel *happy* to be using our APIs than it is to make a scientist happy that we're using his theories
[12:00] <niemeyer> I'll be with you shortly.. will prepare myself a cuppa
[12:23] <Chipaca> Facu: show me show me show me :-p
[12:24] <Chipaca> Facu: does it involve PrefixedEvents
[12:24] <Facu> Chipaca, this is what I have https://pastebin.canonical.com/p/P2f8G9c33y/ , focus on lines 18 and 49, which is what we want to change
[12:24] <niemeyer> > Facu: show me show me show me :-p
[12:24] <niemeyer> > ... how you do that trick ...
[12:25] <niemeyer> Hopefully not the one that makes me scream, tho
[12:25] <Facu> Chipaca, but to really try this I need something "on the other end", I was thinking about installing this charm together with https://jaas.ai/u/ubuntu-ci-engineering/graphite/trusty/1 , and change that FileLogger fake thing with a MetricWhatever
[12:25] <Chipaca> niemeyer: which trick? the muti-coloured one?
[12:25] <niemeyer> We're such a musical group
[12:26] <Facu> I do not want to work "in isolation", I want to have real life examples to have a better grasp on how the changes would "feel"
[12:26] <Chipaca> Facu: sgtm
[12:26] <niemeyer> Chipaca: https://www.youtube.com/watch?v=n3nPiBai66M
[12:29] <Chipaca> niemeyer: hah! these dots i had not connected
[12:30] <Chipaca> in fact i think i might have heard this song once a long long time ago
[12:30] <Chipaca> strange
[12:33] <Chipaca> Facu: wrt PrefixedEvent (and thanks to Dmitrii-Sh for pointing this out) means you do self.on["dumper"] and you get a PrefixedEvent that has non-prefixed events on it
[12:33] <Chipaca> that is, instead of self.on.dumper_relation_joined you do self.on["dumper"].relation_joined etc
[12:33] <Chipaca> so that might be a natural way to go there
[12:34] <Chipaca> Facu: but you're on the right path wrt not doing this in the void
[12:35] <Facu> Chipaca, ack, I'll get a real life example working (but before, that summary I promised about diversity and job offer)
[12:38] <Chipaca> Facu: ok
[12:41] <jam> testing-harness PR updated for single return value
[12:43] <Chipaca> jam: what does ‘# noinspection PyProtectedMember’ do?
[13:28] <Dmitrii-Sh> charm.on[relation_name].relation_joined would be a good way to do it
[13:28] <Dmitrii-Sh> you can't do something like this though: self.framework.observe(charm.on[relation_name].relation_joined, self)
[13:29] <Dmitrii-Sh> because the relation_name part is a charm-specific endpoint and your interface type can't handle that variability
[13:29] <Dmitrii-Sh> self.framework.observe(charm.on[relation_name].relation_joined, self.on_relation_joined)  works
[13:46] <Chipaca> i think i'm going to go for a run
[13:47] <Facu> I don't like the implicitness of that "self" as second parameter, as targets of the events; I think we should encourage people to be explicit there, it's simpler to learn and see each others code (and *maybe* leave that option as an "advanced mechanism", for flexibility)
[13:48] <Chipaca> Facu: yep, we reached the same conclusion
[13:48] <Chipaca> shortly before you joined, we're discouraging the shorthand 'self'
[13:48] <Chipaca> because of what it leads to
[13:48] <Chipaca> but, muscle memory :-)
[13:49] <Chipaca> Facu: this based in part on feedback from users that, seeing 'self', wonder why there isn't just a 'autoconnect_all_the_things'
[13:51] <Facu> Chipaca, this means we will not allow this generic/implicit way? or that we would just encourage the other method?
[13:51] <Chipaca> Facu: the latter
[13:52] <Facu> ack
[13:52] <Chipaca> actually i think we might want to think of doing the former
[13:52] <Chipaca> but for now certainly the latter
[13:53]  * Chipaca postpones the run
[15:13] <Facu> I deployed my charm, which crashed during the install hook call; I fixed it but I can't upgrade it, as it says  unit-my-super-charm-3: 12:11:26 INFO juju.worker.uniter awaiting error resolution for "install" hook
[15:13] <Facu> if I destroy the unit and deploy it again it's fine, but takes a loot
[15:13] <niemeyer> Facu: See juju resolve
[15:13] <niemeyer> Facu: See juju resolved
[15:13] <Facu> niemeyer, thanks
[15:14] <Facu> niemeyer, IIUC I should tell it to no retry, as before I need to upgrade it, right? I mean, it doesn't auto-upgrade it or anything
[15:16] <niemeyer> Facu: It doesn't
[15:16] <niemeyer> Facu: The idea is that after units error out they stop completely
[15:16] <Facu> niemeyer, perfect, thanks
[15:17] <niemeyer> Facu: So you say "go on, you should be good to go now"
[15:18] <Facu> I used --no-retry=True (which would mean something like "please get out of the error state, but hold still") and then upgraded the charm again (which succeeded!! \o/ )
[15:18] <niemeyer> Facu: Not hold still, but just don't retry the hook that failed..
[15:18] <niemeyer> Facu: It may run other hooks
[15:18] <niemeyer> Facu: and the same hook again if it has to for other reasons
[15:19] <Facu> ack, "install" is a one time only hook, right? where all this is documented?
[15:20] <niemeyer> Yeah, one time
[16:14] <Chipaca> jam: is rtype:None the usual way of saying "this returns None"? (asking because None is not a type)
[16:19] <niemeyer> This tastes sooo unpythonic
[16:28] <Chipaca> niemeyer: which this?
[16:28] <niemeyer> rtype:None
[16:29] <Chipaca> heh
[16:29] <niemeyer> I assume that's the type hinting, but maybe not?
[16:29] <Chipaca> it's purportedly picked up by sphynx and presented in nice ways
[16:29] <niemeyer> Ah, sorry.. ECONTEXT
[16:29] <Chipaca> i've been making noises about using python's type hinting (which can be picked up by sphynx as well), which reads nicer imho
[16:30] <Chipaca> but people seem unconvinced :-)
[16:31] <Chipaca> niemeyer: https://github.com/agronholm/sphinx-autodoc-typehints#sphinx-autodoc-typehints is what i meant there
[17:06]  * Chipaca ⇝ cuppa tea
[17:09] <niemeyer> Alright!
[17:09] <niemeyer> Who wants some reviews!?
[17:10] <Facu> niemeyer, I do! https://github.com/canonical/operator/pull/168
[17:16] <Facu> I'm kind of lost about trying a charm and an interface at the same time, probably missing some concepts here and there, I'm kind of stuck...
[17:17]  * Facu needs a rubber duck that actually knows juju and charms
[17:17] <niemeyer> Facu: Reviewed.. I think we need to talk about it
[17:17] <niemeyer> Facu: But not here.. more bandwidth
[17:17] <Facu> niemeyer, https://meet.google.com/veq-yfqm-kdk ?
[17:18] <niemeyer> Great, let's do it
[17:49] <Chipaca> niemeyer: you said 'John--' but i'd already closed the window
[17:50] <Chipaca> niemeyer: I'm going to assume it was "John you're so awesome" until disproven
[17:51] <niemeyer> Chipaca: That was it
[17:52]  * Chipaca ← winning
[18:03]  * Chipaca closes ALL the PRs
[18:06] <Chipaca> niemeyer: if you have a bit of time, I wonder if you have thoughts on https://github.com/canonical/operator/pull/157#pullrequestreview-370519700-body-html
[18:09] <niemeyer> I'll do a full pass before the end of my day, but will take a quick break now
[18:18] <Chipaca> niemeyer: also for when you come back, https://github.com/canonical/operator/issues/178
[18:34] <Chipaca> Facu: #182 fwiw
[18:34] <Facu> checking
[18:37] <Chipaca> Facu: I'd add a static checker to the Makefile but we want less of that arcana, not more :-)
[18:38] <Chipaca> OTOH we could put it in the .travis.yml instead of the Makefile :-D
[18:39] <Chipaca> OTOH² the 'right' way would involve the ast
[18:44] <Facu> Chipaca, I'd not worry about that, this stuff is normally solved by code reviews and education
[18:44] <Facu> Chipaca, not all unpythonicies (?) need to be catched automatically
[18:46] <Chipaca> Facu: unpythonicities* :)
[18:47] <Chipaca> Facu: also, cue Jasper
[18:48] <Facu> Chipaca, "Jasper"?
[18:48] <Chipaca> Facu: https://www.youtube.com/watch?v=sKiLfH3DVGc
[18:48] <Facu> je
[18:53] <Chipaca> I really wonder why there isn't a flag on logging to use format instead of C-style
[18:53] <Chipaca> somebody should PIP that
[19:08] <Facu> Chipaca, I have an item in my projects list to try to do that
[19:08]  * Facu -> short errands
[19:42]  * niemeyer returns
[19:55]  * Facu is back
[21:09] <Facu> YES! I DID IT!
[21:09]  * Facu does the success dance
[21:09] <Facu> I now have my super charm deployed together with postgresql
[21:10] <Facu> my super charm and a custom/fake db interface
[21:10] <niemeyer> Wooahy
[21:10] <Facu> https://pastebin.canonical.com/p/ftCNRZgwrH/
[21:10]  * niemeyer would high-five, but that's disallowed now
[21:10] <Facu> jajaj
[21:11] <Facu> I'm now in the position of starting to really explore the change
[21:11] <Facu> but tomorrow!
[21:11]  * Facu eods
[21:11] <niemeyer> That DBAvailable event really wants me to make StoredState work there
[21:12] <niemeyer> s/wants me/makes me want/


[00:18] <ScottL> is anyone going to be able to test the latest ISOs?
[00:20] <ScottL> TheMuso, how long do you think we have to complete all test cases before the ISOs are to be released?
[00:20] <ScottL> i realize that the 29th is the release date
[00:20] <TheMuso> ScottL: Has there been a new iso notification to the dev list?
[00:21] <ScottL> i'm working on it right now
[00:21]  * TheMuso notes he had a public holiday yesterday so is still going through email from the weekend etc.
[00:21] <ScottL> one came to me (i was subscribed) just today
[00:21] <TheMuso> ah ok.
[00:21] <TheMuso> ScottL: I'd say we have till Thursday.
[00:21] <ScottL> but strangely i wasn't subsribed to the 64bit test though :?
[00:22] <ScottL> but isn't thursday the 29th
[00:23] <ScottL> TheMuso, and just to be clear:  if we don't get all test cases complete the final release of the ISO will NOT happen?
[00:23] <persia> Right, but that shouldn't happen.
[00:23] <TheMuso> ScottL: Correct
[00:24] <persia> The release team will make an increasing amount of noise as the deadline looms.
[00:24] <ScottL> persia, you say that in an egnimatic way....oh, you answered my question, heh
[00:26]  * TheMuso sighs. Jack is going to get a whole lot more messy.
[00:28] <persia> TheMuso: In general, yes, but can't we just pick jack2 and have it just work for us?
[00:28] <TheMuso> persia: Yes. Looks like squeeze will have jack2 by default anyway.
[00:28] <TheMuso> The multimedia guys will get jack2 in, and then worry about supporting multiple implementations later.
[00:28] <TheMuso> Which is fine for us. Jack2 in squeeze will use the same package namespace, which is a no-brainer for us.
[00:30] <persia> RIght, and I think we can (mostly) ignore the supporting-multiple-implementations bit, as long as the solution includes supporting the implementation we selected.
[00:30] <ScottL> i wonder how performance is for jack1 vs jack2     i've read a few post at the forums that were not favorable
[00:30] <TheMuso> Right. We can pick up the multiple implementatino stuff as a bonus later.
[00:32] <ScottL> email sent to -user and -dev list for testing reminder, although it may be a little corny :)
[00:33] <persia> TheMuso: I'd argue that whilst Ubuntu may want the multiple implementation stuff, the Ubuntu Studio team should focus on one solution considered best.
[00:33] <TheMuso> persia: I agree.
[00:33] <TheMuso> And since jack is in main, I feel its my responsibility to maintain it anyway.
[00:34]  * persia needs to chase harder to make "main" go away.
[00:34] <TheMuso> heh
[00:34]  * ScottL hadn't considered that jack2 wouldn't automatically be in the main, hmmmm
[00:36] <persia> ScottL: Let's wait-and-see: it may be that it can drop in without a code-review process.
[00:36] <crimsun> if I can make it to UDS-M, let's discuss the integration bits
[00:36]  * persia notes that even if "main" goes away, there will still be a code-review-process for some stuff
[00:36] <persia> crimsun: Is it schedule or ash that makes that a question?
[00:37] <crimsun> persia: I've transitioned to a position that requires me to be absent for 4-6 months per year, so prep for it is crimping my UDS-M planning
[00:38] <persia> crimsun: Ah.  Good luck with the new role, and I'll hope you are able to make it.
[00:40] <TheMuso> Jack2 is in unstable now, which will be great once Maverick opens.
[00:47] <ScottL> troy and i have been talking (stimulating as always), i think we could benefit by focusing Ubuntu Studio towards university students/audio labs
[00:52] <ScottL> hmmm, no one bit on that.  i'm surprised.
[00:53] <TheMuso> I have no thoughts on that either way.
[00:54] <crimsun> (sorry, I'm head-down looking at the abiword crasher) What's the scope of university students/audio labs?
[00:59] <ScottL> excellent question crimsun, that's what i'm hoping rlamerio, stochastic and i can research and discover
[01:00] <ScottL> but there are lots of them (students, and labs also i would imagine) and it would be great publicity to advertise
[01:01] <ScottL> and since they are in university i would imagine that a percentage of them would have an academic interest in ubuntu studio dev work
[01:02] <ScottL> assuming we are building ubuntu studio for users and we would like to acquire more users
[01:10] <ScottL> to be honest, i do not think our current user base is very broad or dynamic and provides minimal feedback and assistance
[01:10] <ScottL> i gave some thought to perhaps focusing on independent musicians or bands but they had two distinct disadvantageous
[01:11] <crimsun> I certainly concur with the last part of that statement; most users don't really provide feedback
[01:11] <ScottL> 1) most were very likely to be ignorant of ubuntu or linux which would present a distinct and significant obstacle
[01:11] <persia> I don't think that's fair.
[01:12] <ScottL> not insurmountable, mind you but significant
[01:12] <ScottL> why do you say that persia?
[01:12] <persia> When my mother bought her new mic, she went to a Guitar Center, and the clerk there was very happy to help her with other Ubuntu issues whilst recommending a mic.
[01:12] <ScottL> really?  wow, that's outstanding!
[01:12] <ScottL> but i wonder how close that is to nominal
[01:13] <persia> His rationale for using Ubuntu was that it was cheaper than other OSs for audio production.  I imagine that same rationale would apply to a number of other folk.
[01:13] <ScottL> that is very, very true
[01:14] <persia> Used computers can be very inexpensive, and enable interesting things.
[01:14] <ScottL> 2) musician's may not be readily available or accessible
[01:14] <persia> (or rather, far too busy between the day job, rehearsing, and dealing with arranging gigs, etc.)
[01:14] <ScottL> absolutely, i've mentioned my outreach program before, that's what i'm doing, buy cheap computer and installing ubuntu studio on it, giving to a friend interested in recording music
[01:15] <ScottL> but an university offers a static, probably extremely assessable location and most likely very well defined hours
[01:16] <ScottL> they both share a concern about minimizing cost, although the university will have a fiscal budget
[01:17] <ScottL> depending on how liberal (or progressive) the school is, they might even have a open source program
[01:18] <ScottL> this also could translate into high schools, junior highs, and even elementary schools
[01:18] <ScottL> daniel james wrote an article about getting FOSS into his neighborhood school
[01:18] <ScottL> and as troy_s pointed out, these students grow up and take that experience with them
[01:19] <ScottL> reaching out to the schools might even be considered a form of advocacy :)
[01:20] <ScottL> with a quite potentially huge impact
[01:20] <persia> I think that's a sensible and good goal, but don't close the options for others.
[01:21] <persia> Consider instead providing a selection of tools that enables that model whilst still working for arbitrary folks just wanting to create.
[01:22] <persia> As much as I think it's a good idea to have a precise target audience for a flavour, I think it's essential to keep in mind the broader goal of ensuring that software for creators is of acceptable quality and well integrated.  We are respected for doing that now, and it would be a shame to lose that in favour of improving integration in scholastic environments (for which the edubuntu project already provides significant coverage)
[01:25] <ScottL> so, my dream of an audio only, no pulse audio, jack as only sound server, all apps built against jack, fits on a CD release is shattered?  ;)
[01:25] <rlameiro> lol
[01:26] <rlameiro> ScottL: we could try to do a UbuntuStudio JAck series
[01:26] <ScottL> pesia, what's the chances of us releasing two ISOs?
[01:26] <persia> ScottL: Why would you want everything agaisnt JACK?  1) not all software supports that, 2) I don't want to fuss about how my desktop alerts are processed.
[01:26] <ScottL> :P
[01:27] <persia> Exceedingly low unless there's an incredibly good reason.
[01:27] <ScottL> i'm kidding persia, sorry
[01:28] <persia> also, recognise that we share packages with the rest of Ubuntu, so we want to try to not do anything that makes any software not work in multiple environments.
[01:36]  * ScottL 's 3 yo has been crying about the walle movie :(
[01:36] <ScottL> sorry, persia, i was kidding about my jack only dream
[01:37] <ScottL> i know pulse is staying and quite frankly i'm glad were finally getting towards (hopefully) a good integration with jack
[01:37] <ScottL> i think that would be a huge milestone in the project, it certainly would gratify a lot of the users
[01:38] <persia> Indeed.  Before pulse, all was fine: audio was just broken, and people could use JACK.  Then it got confusing as polyp became pulse and started to make things work.  Soon we can get to the new place, where audio just works, and people can use JACK.
[02:16] <ScottL> rlameiro, did you file a bug against network-manager?
[02:17] <rlameiro> not yet
[02:17] <persia> Which bug against network-manager?
[02:17] <rlameiro> network-admin
[02:17] <ScottL> the one that rlameiro posted pictures of empty choices
[02:17] <ScottL> sorry, wrong package on my part
[02:18] <persia> OK.  The gnome-network-admin bug.  Right.
[02:18] <persia> I thought we had *another* one, and was worried.
[02:18] <rlameiro> lol
[02:18] <ScottL> sorry again, persia, i'm not trying to raise your blood pressure tonight, seriously :)
[02:19] <ScottL> but persia, if we get this bug addressed will it address many of the users concerns about networking?
[02:19] <ScottL> and by networking I was presuming they meant wi-fi
[02:19] <persia> Should do.  Looks easy to fix.  I don't believe we could get approval from the release managers to do it for lucid though.
[02:19] <persia> Mind you, it might expose some other bugs, but that's fine :)
[02:20] <ScottL> that's the price of progress sometimes :)
[02:20] <persia> (hard to know if we have networking bugs if we can't even access the network administration interface)
[02:21] <ScottL> but if we address the networking bug and get jack2/pulse audio playing nice, then that's a nice bit of improvement
[02:21] <ScottL> and would address the most common user complaints i believe
[02:22] <persia> Indeed, and if we sort those in maverick, although with other improvements, we ought be able to recommend all users to upgrade, and avoid too much pressure to do lots of LTS support.
[07:07] <jussi> Have you guys notcied this? http://www.lionstracs.com/store/
[07:10] <hansfbaier> jussi: SPAM?
[07:20] <jussi> hansfbaier: huh?
[07:21] <jussi> hansfbaier: just pointing out something that runs on linux, as featured on the kubuntu lead devs blog...
[07:50] <astraljava> jussi: I'm sure [s]he just doesn't recognize your nick. :D
[07:51] <jussi> astraljava: ahh, likely.
[08:29] <hansfbaier> jussi: was not to sure about the url, looked like some shady store out there, wasn't brave enough to open it.
[08:30] <hansfbaier> jussi: pretty cool gear
[08:34] <jussi> hansfbaier: :) thats fine. yeah, it looks pretty nice stuff
[09:38]  * abogani is wondering if someone of this Team will partecipate at UDS-m...
[09:47] <jussi> abogani: o/ me
[09:55] <abogani> jussi: Please if you'll have a chance could you show the needed for UbuntuStudio project to have a -lowlatency kernel or (more simply) the -preempt flavour for i386 also (it si already present but only for amd64)?
[10:25] <persia> jussi: FYI, Lionstracs used to ship with 64Studio.
[10:25] <jussi> persia: ahh
[10:43] <abogani> persia: Who is Lionstracs?
[10:44] <persia> abogani: A company that makes keyboards based on linux.
[10:46] <abogani> persia: Thanks.
[11:20]  * persia needs faster sync: the last sync job hasn't completed yet :(
[11:56] <ScottL> persia, do you mean for the ISO?  I noticed that it took quite a bit longer for me too, but i used zsync this time instead of rsync
[11:57] <persia> Yes, but the comment was mistargeted: it belonged in #ubuntu-testing :)
[12:00] <rlameiro> new test cases out
[12:01] <rlameiro> i will try to make the same test for AMD64
[12:01] <rlameiro> all but the encription one
[12:23]  * persia will do encryption again if someone else doesn't get to it first, but hopes to concentrate on bugfixing
[15:35] <persia> ScottL: You about?
[15:37] <persia> ScottL: Seems you're already in -release :)  Anyway, slangasek is hunting about release announcement stuff, and you seem like the right contact.
[15:55] <ScottL> persia, sorry, son has been sick and i'm staying home with him, not checking too often on channel
[15:55] <ScottL> but, yes, i am here, reading now
[15:55] <persia> Hope he gets better soon.
[15:56]  * abogani hope the same.
[16:02] <ScottL> he's feeling better already, but he was up (and so we were) a few times last night while he was vomiting :(  no fun for anyone
[16:04] <persia> Oh, good.  Annoying night, but better in the morning is always hugely calming.
[16:07] <ScottL> release notes complete
[16:16] <persia> Does slangasek know?
[16:20] <ScottL> yes, i told him in -release channel
[16:21] <persia> Cool.  Thanks a lot!
[16:24] <ScottL> that's what i'm here for :)
[16:24] <ScottL> if i couldn't get things done i probably wouldn't be here ;)
[16:29] <persia> heh
[17:40] <rlameiro> ScottL persia just submitted 3 test reports to the QA on the AMD64 iso
[17:41] <rlameiro> now is missing the encrypt one
[17:41] <persia> rlameiro: Thanks!
[17:41] <persia> rlameiro: I hope you linked the network bug, etc.
[17:41] <rlameiro> persia: i didnt
[17:41] <rlameiro> sorry
[17:41] <rlameiro> but i can modify it
[17:41] <persia> Please do.
[17:41] <rlameiro> is there a bug report on lp?
[17:42] <persia> We need to indicate that the release is buggy in the ways we know it to be buggy.
[17:42] <persia> You've been saying you'd file it :)
[17:42] <persia> But it's essential to have these bugs so we can verify the release notes cover them.
[17:42] <rlameiro> ok, i will try to do it now
[17:43] <rlameiro> i am on middle of teaching, a student is late, so i will strat to file the bug
[17:43] <rlameiro> where do i file it? ubuntustudio or general ubuntu?
[17:50] <ScottL> i'm hoping to get most of the i386 this afternoon
[17:51] <persia> rlameiro: Run `ubuntu-bug gnome-network-admin` on a finished lucid install (one of the tests)
[17:52] <rlameiro> persia: i am filing it directly on launchpad
[17:52] <persia> Please don't: the automated reporter adds all sorts of useful information.
[17:53] <persia> But if you really must, it's against /ubuntu/+source/gnome-system-tools
[17:58] <rlameiro> yes i knbow
[17:58] <rlameiro> i just need to know the package version
[17:58] <rlameiro> is anyone on 10.04
[17:59] <rlameiro> persia: the problem is that i cant do that because i dont have network in 10.04.....
[17:59] <persia> OH, heh, right.
[17:59] <persia> Don't worry about the version then.
[17:59] <persia> Nor about the automatic filing.
[17:59] <rlameiro> i will let a note, that i didnt filed the bug via apport because i didnt had network
[18:01] <rlameiro> !570828
[18:01] <rlameiro> how do i ask for the bug?
[18:01] <rlameiro> !ubottu 570828
[18:01] <rlameiro> lol
[18:01] <rlameiro> !bug 570828
[18:02] <persia> Thanks!  Now link it to your tests in the ISO tracker.
[18:02] <persia> (ask in #ubuntu-testing if the procedure isn't obvious)
[18:03] <rlameiro> persia: done
[18:03] <rlameiro> http://iso.qa.ubuntu.com/qatracker/test/4129
[18:28] <rlameiro> persia: please look at the bug
[18:28] <rlameiro> some guy made it invalid
[18:28] <rlameiro> ......
[18:28] <rlameiro> grrrrrrrrrrrr
[18:28] <rlameiro> why dont they read before
[18:38] <abogani> rlameiro: Studio don't use NetworkManager?
[18:40] <rlameiro> no
[18:40] <rlameiro> abogani: it uses gnome-network-admin
[18:42] <abogani> funny
[20:09] <ScottL> rlameiro, i set the bug back to new and explained to Milan that it's for ubuntu studio lucid (not hardy and not just ubuntu)
[20:09] <ScottL> hopefully i didn't make anyone upset :)
[20:10] <ScottL> and thanks for filing the bug
[20:10] <rlameiro> np
[20:49] <rlameiro> stochastic: thanks for changing the state of the bug...
[20:50] <rlameiro> persia: did you readed the bug?
[20:52] <rlameiro> they are debating why we dont use the network manager
[20:52] <rlameiro> maybe someone should expllain why ubuntustudio doesnt use it
[20:55] <stochastic> rlameiro, I did what to which bug?
[20:56] <rlameiro> stochastic: to the network bug
[20:56] <stochastic> how long ago was that?
[20:56] <astraljava> I think that was ScottL, not stochastic.
[20:57]  * stochastic thinks so too
[20:57] <rlameiro> arent you eric?
[20:57] <stochastic> yes I am, what's the bug number
[20:58] <rlameiro> https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/570828
[20:59] <ScottL> i changed the bug
[20:59] <stochastic> yup, I haven't touched that one
[20:59] <rlameiro> ah
[20:59] <rlameiro> ok
[20:59] <ScottL> i'm sure there was a good reason for Studio's choices (i just wished i knew what it was)
[20:59] <rlameiro> oops
[20:59] <rlameiro> yeah
[21:00] <rlameiro> i must imagined that
[21:00] <rlameiro> sorry stochastic
[21:02] <astraljava> I think persia explained it just a day or two ago, something to do with using resources all the time scanning for wireless networks etc (NetworkManager), instead of just using resources when user actually configures networking (gnome-network-admin).
[21:03] <astraljava> Dig back from the backlog, it shouldn't be too hard to find. :)
[21:03] <stochastic> ^^ yes, and the added fact that many studio boxes will not need to be connected to the internet in a true studio setup
[21:04] <rlameiro> stochastic: well, that doesnt seems to me like the majority of the cases...
[21:04] <stochastic> rlameiro, I wasn't involved in the decision, I just recall that as one of the talking points at the time
[21:04] <rlameiro> astraljava: they are asking for that info, maybe i cant point them to the logs
[21:04] <rlameiro> stochastic: I know
[22:36] <ScottL> amd64 ISO full disk w/ encryption test case still needs to be completed
[22:37] <ScottL> i386 ISO test cases are all complete
[23:01] <TheMuso> WHo is writing a release announcement?
[23:15] <detrate> nice, I just got my new Hercules DJ Control Steel in
[23:25] <ScottL> TheMuso,  i think stochastic did it last time, but what does it entail?
[23:25] <ScottL> isn't it just mainly the release notes?
[23:26] <TheMuso> ScottL: yes
[23:26] <TheMuso> slangasek: was asking about them in #ubuntu-devel.
[23:27] <ScottL> i believe i took care of that TheMuso   https://wiki.ubuntu.com/UbuntuStudio/10.04release_notes
[23:28] <TheMuso> ScottL: ok does slangasek know about that?
[23:28] <ScottL> persia pointed me at where slangasek was asking about release notes and i took care of it and then told him so
[23:28] <ScottL> TheMuso, yes
[23:28] <TheMuso> ScottL: ok thanks
[23:28] <ScottL> always glad to help
[23:36] <ScottL> persia: will you be able to get the last amd64 test (w/ encryption) ?


[07:39] <\vish> Amaranth_: Hi... :) you know about alacarte right?
[10:54] <[wa55up]_> hi
[10:54] <[wa55up]_> did anyone get to work feeds applet 0.3.9 on awn??
[21:27] <bcurtiswx> bug #496182 the ubuntu desktop bugs team needs to be assigned to the other package in the bug
[21:32] <mac_v> bcurtiswx: it is how it was designed... once user quits it shows offline
[21:32] <mac_v> the shutdown icon isnt used after empathy icon is used
[21:32] <bcurtiswx> mac_v: I believe the report is saying that doesn't happen.. it goes to greyed out not the "power" icon
[21:33] <bcurtiswx> mac_v: hmmm
[21:33] <mac_v> bcurtiswx: let me get you the bug #
[21:34] <bcurtiswx> ok
[21:35] <mac_v> bcurtiswx: Bug #432635 , comment 25
[21:37] <bcurtiswx> mac_v: yes i see this.  What your report says is that it start out as power icon then goes to status icons.. My report says that when you exit it, the icon should go back to the power one and it doesn't
[21:37] <mac_v> bcurtiswx: pls read comment 25.. :)
[21:38] <mac_v> on the bug report i gave
[21:39] <mac_v> bcurtiswx: AFAIK , it wont be fixed for karmic... probably when Memenu lands this will be solved
[21:39] <mac_v> in lucid
[21:41] <bcurtiswx> mac_v: maybe im still not seeing something.. I have read comment #25.  All Comment #25 says is that it starts out with the power icon.  Once an IM program is loaded is switches to status icons.. I know that.  The action that I get when EXITING pidgin, is that it goes back to the power Icon.
[21:41] <bcurtiswx> thats what I believe to be the correct action
[21:42] <bcurtiswx> the bug report says that when exiting empathy, it doesn't go back to the power icon
[21:42] <\vish> bcurtiswx: ah... then its a bug in pidgin :)  it also needs to display the pffline status
[21:42] <\vish> offline*
[21:44] <bcurtiswx> mac_v: would this be an indicator-session problem and not a pidgin problem?
[21:44] <\vish> bcurtiswx: well ... kenvandine would know more
[21:45] <\vish> bcurtiswx: the thing with empathy is  , it does quit entirely... so even when you quit the app telepathy is running
[21:45] <bcurtiswx> kenvandine: pidgin currently causes the indicator-session to go back to the power icon upon exiting the program.  Is this a pidgin problem or a indicator-session problem?
[21:45] <\vish> does not*
[21:46] <bcurtiswx> mac_v: i would first assume the status icon "offline" would pertain to setting your IM status as offline although still having the program loaded.. and the power icon symbolizing NO IM programs running
[21:46] <bcurtiswx> just my opinion tho
[21:47] <bcurtiswx> i will wait for kenvandine's response
[22:34] <Sarvatt> is it expected that the radio buttons to convert between bases in dont show up in gcalctool any longer? also, if a number has any non numeric digits even in hex input mode it wont show the binary representation in programming mode
[22:35] <Sarvatt> sorry for the extra "in" the first sentence there :D
[23:25] <Sarvatt> just bisected both gcalctool problems to this commit http://git.gnome.org/browse/gcalctool/commit/?id=0be7b51eeb71395072bc037ac32b06d18e63cdd0
[23:34] <Sarvatt> looks like the base conversion (and bitwise length) radio button removals were intentional and moved to the preferences menu for screen space, but i'm still having the problem where the bit panel is greyed out if a-f is used


[09:14] <ogra> lool, weird, the nighly alternate build works, the manual build i did before going to bed produced an image that was 512 byte to small to fit the VFAT on
[09:14] <ogra> i suspect we need to keep an eye on that
[09:29] <lool> So it hit the check on th size of the vfat?
[09:29] <ogra> yeah
[09:29] <lool> It's hard to tell whether stuff will fit in the vfat; I should probably allocate some extra space but then it's lost space  :-/
[09:30] <ogra> did we take the 512 bytes into account we need for the MBR ?
[09:30] <ogra> it bothers me that its excatly 512 bytes
[09:30] <lool> What is the vfat on the disk image or in the vfat?
[09:31] <lool> What's the output?
[09:31] <lool> If it's in the disk image, it might be solved by the CHS work I had done in jaunty
[09:31] <lool> But didnt deploy as I had found the real bug sometimes afterwards
[09:33] <ogra> creating VFAT partition...
[09:33] <ogra> WARNING: You are not superuser.  Watch out for permissions.
[09:33] <ogra> VFAT partition length is 688913920B and doesn't leave enough room for VFAT 688914432B
[09:33] <ogra> make: *** [bin-images] Error 1
[09:33] <ogra> ERROR WHILE BUILDING OFFICIAL IMAGES !!
[09:34] <ogra> sorry took a moment
[09:34] <lool> So that's in the disk image
[09:34] <ogra> we really should have splitted logs
[09:34] <ogra> its very hard to find something
[09:34] <lool> Could you try with antimony ~lool/debian-cd-chs-addressing.patch ?
[09:35] <ogra> well, it worked with the automatic build some hours later
[09:35] <lool> Ah
[09:35] <ogra> i'm not sure its easily reproducable
[09:35] <lool> Well if it rehappens, please try that patch
[09:35] <ogra> i will