[06:56] <adamant1988> hi all
[07:02] <troy_s> greetings all
[07:14] <Madpilot> hi
[07:26] <troy_s> Mad!
[07:26] <troy_s> How you doing?  Sorry I was catching up on a plethora of mail.
[07:26] <Madpilot> np, doing well. Messing with Inkscape
[07:26] <troy_s> Good stuffs.
[07:28] <troy_s> how is it going?
[07:28] <troy_s> lots of good stuff happening for the artwork team.
[07:29] <Madpilot> looks like it, I've been stupidly busy the last week and barely following email
[07:30] <Madpilot> Inkscape "Trace Bitmap" coolness: http://www.warbard.ca/temp/B17-prop.svg
[07:30] <Madpilot> destined for openclipart.org eventually :)
[07:51] <troy_s> laf
[07:51] <troy_s> yah ditto.
[07:51] <troy_s> busy as hell... AND paris is rapidly approaching.
[07:51] <troy_s> yo mad...
[07:51] <troy_s> are you on launchpad?
[07:52] <troy_s> That traced bitmap is pretty damn cool!
[07:52] <troy_s> Amazing vert to SVG really... quite interesting for a technique.
[07:52] <Madpilot> troy_s, I'm bburger on LP
[07:52] <troy_s> are you on the ubuntu-art team?
[07:52] <Madpilot> yes
[07:52] <troy_s> ahhh yes of course you are.
[07:53] <troy_s> can you check your mail?
[07:53] <Madpilot> I just tweaked that whiteboard thing, actually
[07:53] <troy_s> i just registered a specification to ubuntu-art to try and test the
[07:53] <troy_s> cool.
[07:53] <troy_s> !
[07:53] <troy_s> so it went out?
[07:53] <troy_s> How fecking cool is that?  Wow.  Who would have guessed.  laf.
[07:53] <troy_s> Bloody handy feature.
[07:54] <Madpilot> although it looks like there's no email notification of spec creation, just editing?
[07:55] <Madpilot> I've got that chunk of LP documentation bookmarked to read over the weekend
[08:00] <troy_s> well you have to assign someone
[08:00] <troy_s> again, there just ISNT a central area for all this knowledge, so i am having to do a little legwork.
[08:00] <Madpilot> yeah
[08:00] <troy_s> thankfully neil and a few other folk shave started contributing.
[08:00] <Madpilot> Launchpad needs a DocTeam :)
[08:00] <troy_s> and the results are massive.
[08:01] <troy_s> well i think docteam's plate is pretty damn full.
[08:01] <troy_s> needless to say, for our purposes, we can kill two birds by documenting our individual progress in a centralized wiki page for all artwork team members to reference.
[08:01] <troy_s> which is a helluva lot better than just dumping your jetty to the mailing list and thinking that it somehow magically will happen.
[08:01] <Madpilot> troy_s, I wasn't volunteering Ubuntu's DocTeam, I was suggesting that LP get it's own
[08:02] <troy_s> yep... i understood that :)
[08:02] <troy_s> but hell... docteam is docteam.  laf.
[08:02] <Madpilot> ha. People have tried to assign random stuff to DocTeam before, it didn't go over very well ;)
[08:03] <troy_s> launchpad is a great resource, but no one really has used it for our team, and the information is _scarce_
[08:03] <troy_s> i bet
[08:03] <troy_s> especially considering that doc team didn't exist until recently thanks to a few committed individuals.
[08:03] <troy_s> it was just as our 'team' currently is.
[08:03] <troy_s> scattered and useless.
[08:03] <Madpilot> DocTeam came together in a huge way for Dapper release
[08:03] <troy_s> with a few folks who silently plod along on particulars.
[08:03] <troy_s> oh yeah!
[08:04] <troy_s> make no mistake, i have been looking at them quite a bit lately...
[08:04] <troy_s> some things i think we can do better, of course ;)
[08:04] <Madpilot> ArtTeam also seems to have a few people who delight in endlessly re-arranging our wiki pages, I've noticed ;)
[08:04] <troy_s> that svg is cool as hell... how do you scale those svgs?  inkscape?
[08:05] <Madpilot> yes
[08:05] <troy_s> laf.
[08:05] <troy_s> well the re-arranging kind of started with me being pissed with the outdated nature and a general lack of structure.  then bersace put in a lot of legwork to refine it -- with the goal to be an overhaul.
[08:06] <troy_s> needless to say, it is at least evolving.
[08:07] <Madpilot> yeah. docteam's never done much over the wiki, really - mostly ML and of course the actual docs are in an SVN repo
[08:07] <troy_s> the only _real_ issue is that english isn't et's first language, so he needs some help proofing and such.
[08:07] <troy_s> well wikis are useful in a number of ways -- for one, the number of new artwork folks who are at least observing and participating has shot up huge.
[08:07] <Madpilot> noticed that too, but proofreading is something I'm better than most at :)
[08:07] <troy_s> because there is a little info there now.
[08:07] <troy_s> great!
[08:08] <troy_s> you should help him out... he is quite a mule when it comes to slogging out the dirty bits that no one else will attempt.  eager as heck to get it in order too i might add.
[08:09] <troy_s> i'm a bit of a stickler for spelling and grammar, but my schedule isn't terrific so I need to target my energy rather tactically at the moment.
[08:10] <Madpilot> troy_s, are you going to Paris? (being sponsered?)
[08:10] <troy_s> yes i am going to paris.
[08:10] <Madpilot> cool
[08:10] <troy_s> which is horrible because my french stinks (although not as bad as some folks)
[08:11] <troy_s> and i _really_ feel like a fish out of water when meeting people i have only chatted with via email.
[08:11] <troy_s> but alas, c'est la vie.
[08:11] <Madpilot> oui
[08:11] <troy_s> At least being Canadian I was forced to learn a little basic French.
[08:11] <Madpilot> "Biere, s'vous plait" - tres important ;)
[08:12] <troy_s> Laf.
[08:12] <troy_s> Mon stylo et grande et jaune.
[08:12] <troy_s> Do you think you would be able to help out et with the wiki reorganization?
[08:12] <troy_s> (and it goes without saying that we are all horribly busy.)
[08:12] <troy_s> but as i have tried to stress... many hands make for light work.
[08:13] <Madpilot> I'll see what I can do, et & others seem to have it well in hand, and to have a definite vision they're pursuing
[08:13] <troy_s> anyone else in the channel of late?
[08:13] <troy_s> well not quite... the amount of contribution currently is slim
[08:14] <troy_s> et is a very good team player too... so i imagine he would be open to having some help.
[08:19] <troy_s> hrrm... who changed the topic?
[08:21] <troy_s> pascal's in the house
[08:21] <msikma> so am I
[08:22] <troy_s> hey mich -- how you doing?
[08:22] <msikma> Unless you mean those who are going to Paris
[08:22] <troy_s> there he is
[08:22] <troy_s> greetz pas.
[08:22] <msikma> I'm doing fine, thanks. I just finished a proposal for a redesign of the main page. I don't like what's currently on there. So I'll just pipe that into the mailing list soon.
[08:22] <troy_s> main page?
[08:22] <msikma> The Ubuntu main page
[08:23] <klepas> hey
[08:23] <troy_s> oh...
[08:23] <troy_s> well be careful
[08:23] <troy_s> because henrik is a wonderful guy.
[08:23] <troy_s> and i think he has had the bulk of that workload dumped on him with little support.
[08:23] <msikma> Ah, I see
[08:23] <troy_s> so phrase carefully
[08:23] <troy_s> :)
[08:23] <msikma> Yeah, I'll do that :)
[08:23] <troy_s> who changed the topic?
[08:23] <klepas> troy_s: as you have admin rights to the launchpad team could you please add the meeting time
[08:23] <klepas> to the calendar
[08:24] <klepas> topic is the same as of last time we spoke :)
[08:24] <troy_s> klepas:  yeah i was working on trying to figure out a way to hit the members with mail.
[08:24] <troy_s> is it?
[08:24] <klepas> yes
[08:24] <troy_s> ahhh mine is because i tried to change it.  weird.  i must have been opped before.
[08:24] <troy_s> but i don't recall seeing it.
[08:24] <msikma> It's not really a total redesign, actually, it's just moving around some things and "fixing" some things such as stretched type and the usage of the Ubuntu font for other things than the actual logo, which I think might not be that suitable. http://thingmajig.org/tmp/ubuntuhomepage_proposal.png
[08:25] <msikma> And other small things such as the logos to the right not being lined up exactly correctly.
[08:25] <troy_s> msikma:  agree though.  a website is such a monumental task too...
[08:26] <msikma> I'll just quickly write up some thoughts and then head off to work.
[08:27] <msikma> Oh, by the way
[08:27] <troy_s> klepas
[08:27] <troy_s> what do you want for a description?
[08:27] <msikma> Does Henrik monitor the art mailing list?
[08:28] <troy_s> yes.
[08:28] <troy_s> i believe he does... but as a VERY active ubuntu member, he is probably swamped with backlogs of mail.
[08:29] <troy_s> klepas?
[08:29] <klepas> troy_s: "This meeting will lay down some leadership positions and begin organising ourselves so we can soon begin creating some rocking art."
[08:29] <klepas> mhh
[08:29] <klepas> let me reword that
[08:30] <troy_s> there... it is added.
[08:30] <troy_s> of course i added it before you shipped that blasted summary :)
[08:30] <klepas> "This meeting will focus on the leadership and organisation of the team such that we can soon begin to create some rocking art."
[08:30] <troy_s> i think it might be wise to treat it as a pre-meeting to see who is active out there and who can get themselves into irc.
[08:30] <klepas> i'll post the agenda in the next few hours
[08:31] <troy_s> further still, it appears that Mark has ideas for a driver based team.
[08:31] <troy_s> klepas did you manage to squeeze one out?
[08:31] <klepas> could you please link to the wiki meeting agenda page in that calendar description
[08:31] <klepas> troy_s: not as of yet. in the next few hours it will be up on the wiki and in the  ML
[08:31] <troy_s> 49 members... interesting.
[08:32] <klepas> i hope the turnout is not that large ;)
[08:32] <troy_s> klepas:  its a wiki bro.  you are a launchpad member, no?
[08:32] <troy_s> i would hope the opposite.
[08:32] <troy_s> i am interested to see who is lurking out there on the mailing list.
[08:32] <troy_s> although i have a pretty good idea based on the sheer volume of mail that i get to sort through every day in my private box... laf.
[08:33] <klepas> do you think it should be noted in the calendar description who will be chairing?
[08:33] <klepas> such that people know beforehand when i tell people to keep on track...
[08:34] <troy_s> no clue.
[08:34] <klepas> no worries
[08:34] <klepas> actually
[08:35] <klepas> i'll stick it into the agenda
[08:35] <troy_s> once you put up your notion of an agenda, i would think that it might be clearer.
[08:35] <klepas> so that people know beforehand, especially for latecomers
[08:35] <klepas> how long will you be online
[08:35] <troy_s> for a bit more...
[08:36] <troy_s> i am going to adjust some more docs stewing and tend to some further email.
[08:36] <klepas> because i could really do with a nap before doing this agenda
[08:37] <msikma> Wham, mail sent.
[08:38] <msikma> Okay, so, when's the meeting again? It's on a saturday, right?
[08:38] <troy_s> its on launchpad.
[08:38] <troy_s> for those who can attend.
[08:38] <msikma> Maybe you could add it to the topic here so I can memorize it :P
[08:38] <troy_s> although, judging from irc participation, i suspect it will be... dribbly
[08:39] <troy_s> msikma:  i would but i can't change the topic of late.
[08:39] <troy_s> no ops.
[08:39] <troy_s> but launchpad has it.
[08:39] <msikma> Oh, I see, so all the ops on the access list aren't active anymore? Maybe we should ask a freenode staffer to fix that.
[08:39] <troy_s> there aren't any ops here.
[08:39] <klepas> msikma: Saturday June 17, 16:00 UTC, in #ubuntu-meeting
[08:40] <troy_s> but i know for certain i was able to change it previously.
[08:40] <troy_s> klepas:  crappers.  i put it in #ubuntu-art
[08:40] <msikma> There must be at least one op in a channel.
[08:40] <klepas> :)
[08:40] <troy_s> msikma:  not on public servers necessarily.
[08:40] <msikma> The owner of the channel is one who always has access.
[08:40] <Madpilot> troy_s, this channel is +t now - only ops can change the /topic
[08:40] <klepas> troy_s: could you add the description i mentioned above below what you wrote?
[08:40] <troy_s> msikma:  yah but you get a default op by leaves.
[08:40] <troy_s> and netsplits.
[08:41] <troy_s> who put the plus t in i wonder.
[08:41] <Madpilot> no idea - last person to change the topic was you, troy_s
[08:41] <msikma> Well, I'll look into it later, I gotta go now
[08:41] <msikma> See you later
[08:41] <troy_s> wtf is that about?
[08:41] <troy_s> i didn't plus t it
[08:42] <klepas> troy_s: https://wiki.ubuntu.com/ArtworkTeam/Meetings/Agenda add that to the description
[08:42] <klepas> on the calendar
[08:42] <troy_s> klepas:  only problem is that there isn't a clear edgy target spec yet.
[08:43] <troy_s> klepas:  not until the dev meeting.
[08:43] <klepas> we don't need to come up with one
[08:43] <klepas> yea
[08:43] <klepas> we'll discuss the leadership and organisation
[08:43] <troy_s> klepas:  and it also seems like mark has some things planned or at least loosely set into motion.
[08:43] <klepas> and then lay down some fundamental goals
[08:43] <klepas> just simple stuff
[08:43] <klepas> like "get our art into edgy mainstream"
[08:44] <troy_s> LAF
[08:44] <troy_s> not a bad goal.
[08:44] <Madpilot> goals like "No waiting until 24hrs before release to debate which themes we're including"
[08:44] <troy_s> that was a great one
[08:44] <klepas> oh, that too :)
[08:44] <troy_s> who deserves a lot of credit for that
[08:44] <troy_s> he did a tremendous amount of work
[08:44] <troy_s> since this is irc
[08:44] <klepas> Madpilot: hope that get's fixed by the organisational issues that we have/will soon solve
[08:45] <troy_s> it is probably a good place to discuss some concerns.  mine are largely that A) we have six months (which if you have ever developed ANYTHING professionally know that it just isn't a lot of time)
[08:45] <klepas> troy_s: i'd like for you to go over the agenda once i've finished it
[08:45] <troy_s> B) Ubuntu default theme / interface is horribly scattered with elements of true professionalism and elements of 'hey what the hell'
[08:45] <klepas> i think 6 months is good
[08:45] <Madpilot> troy_s, we don't have six months. We've got about 4 & a half, assuming Edgy goes right back to it's October release date
[08:45] <troy_s> 6 months IS good if we have a VERY formal structure in place with hard deadlines -- i agree.
[08:46] <klepas> and B) is arguable. it's an opinion which some people disregard and others go beyond even
[08:46] <troy_s> mad -- good point!
[08:46] <troy_s> klepas:  so you think the default is where it should be?
[08:46] <klepas> i think there are some crap things in the current theme
[08:46] <troy_s> klepas:  i tend to agree with franks summary for the large.  i REALLY like the gnome splash, for example, but it feels out of place with the desktop wall.
[08:46] <klepas> but there is also some good stuff
[08:47] <klepas> yea, i agree... splash is great but wallpaper isn't and doesn't fit
[08:47] <troy_s> but again, these sorts of artistic issues can't be resolved without a formal structure for following.
[08:47] <troy_s> meaning no color submissions for proofs of principle.
[08:47] <troy_s> etc.
[08:47] <klepas> and note we did not create that art
[08:47] <troy_s> start with simple, then vote, then keep cleaning up and polishing...
[08:47] <troy_s> etc.
[08:48] <troy_s> it really needs to be more like a formal sculpture than a hodge podgey submit and hope for a dart to hit the board sort of thing.
[08:49] <troy_s> and, to have ANY chance, we need to at least make ONE hard release goal to test our packaging and conversational abilities with the rest of the team.  do you know what i mean?
[08:49] <klepas> yes
[08:49] <troy_s> that is, one hard PRE-release goal (eg dapper flight), before final etc.
[08:49] <klepas> i'd like to add something to what you've just brought up
[08:49] <troy_s> personally, i find i kind of look forwards to the 'new' look of every ubuntu release.
[08:49] <troy_s> i don't know how you all feel on it.
[08:50] <troy_s> i like the idea of having a new usplash, etc and others that i have tried to start listing via targets etc.
[08:50] <troy_s> yah go add.
[08:51] <klepas> I personally think that the best way to go about creating good artwork that fits together (ie. the splash follows some similar styling to other artwork such as the wallpaper) would be to make sure people know this but then allow people come up with various artwork which they can freely choose the style for
[08:51] <klepas> then, maybe half-time
[08:51] <klepas> we consider the artwork available and decide on one of the themes
[08:51] <klepas> "themes/styles"
[08:51] <klepas> and go with it
[08:51] <troy_s> klepas:  absolutely.  the idea as per the design doc is to have a given time limit on pondering -- meaning that we all arrive at some general textures, motifs, etc.
[08:51] <klepas> because that way it's a more open process
[08:51] <klepas> yes!
[08:51] <troy_s> for example, maybe with compiz and such for edgy we suggest something like maybe glass, tranlucency, etc
[08:52] <troy_s> then work on some mock ups for each target
[08:52] <klepas> we can't have this go on for months... maybe just in the first
[08:52] <troy_s> nope
[08:52] <klepas> however
[08:52] <troy_s> i based my estimates on a six month cycle.  ponder i think was allocated 1.
[08:52] <klepas> it is important to realise the existing artwork
[08:52] <klepas> _especially_ the GDM theme
[08:52] <troy_s> ?
[08:52] <klepas> Mark does not want to change
[08:52] <troy_s> is that a statement or are you typing more?
[08:52] <klepas> more :)
[08:52] <troy_s> hrm... where are his references to it?
[08:53] <troy_s> the GDM theme has been static for a number of releases, and i strongly suspect that if we were successful as a team to create an entire cohesive set of art bits for edgy, he would be more than likely to approve it.  that said, if we flounder as we have, the chances are high that 'what works' will stick.
[08:53] <klepas> The GDM theme has been around for a while now and is quite well known. It has not been changed for several releases now (can't remember where it first appeared... Hoary or maybe even Warty).
[08:54] <klepas> true that
[08:54] <troy_s> yah but is that because it is a mandate or because there simply is no damn artwork team?
[08:54] <troy_s> laf.
[08:54] <troy_s> hell... i can get an answer to that pretty darn quick.  in fact, i will do that before leaving tonite.
[08:54] <klepas> but we should keep in mind that changing existing artwork each release is not as important as providing artwork in areas missing consistency or with a complete lack of artwork
[08:54] <troy_s> klepas:  which is exactly Frank's point...
[08:54] <klepas> :)
[08:55] <troy_s> klepas:  my personal opinion is that we have a set number of 'new' targets for each release -- meaning just enough change to make people go 'ooooh cool new look', and yet is easily attainable within six months...
[08:55] <klepas> so we should focus more on Tangerine, Tango, a splash, some wallpapers and perhaps a better Metacity theme
[08:55] <troy_s> klepas:  and in the background make sure details like Frank's list make completion.
[08:55] <klepas> in my humble opinion
[08:55] <troy_s> Well what exactly is tangerine in its totality?
[08:55] <troy_s> as far as i can see... human is default correct?
[08:56] <troy_s> and human is sort of a fork off of tangerine, no?
[08:56] <klepas> Tangerine came about as an icon set made by the community
[08:56] <troy_s> (strictly speaking icon work -- and i would say icons are the LAST thing to get changed as they are massive -- and they need finishing)
[08:56] <klepas> because the community could not contribute to Human
[08:56] <troy_s> why could they not contribute to human?
[08:57] <troy_s> and i think human was funded by mark via iconfactory iirc?
[08:57] <klepas> and as Mark does not like Tango very much and wanted a branded icon set Lapo and Andreas stood up offering examples of Human style-Tango-style icons
[08:57] <klepas> which we made by the community, in a short period of time
[08:57] <troy_s> you have links to tango handy?
[08:57] <klepas> Human is being produced using proprietary tools, as it seems and by a contracted artists through Canonical
[08:57] <klepas> sure
[08:58] <troy_s> yes i heard it was iconfactory.
[08:58] <klepas> http://www.tango-project.org
[08:58] <klepas> Lapo, Andreas and I use it... :)
[08:58] <klepas> it's much more consistent than Human
[08:58] <troy_s> but i was under the impression that iconfactory was assigned the work because there simply wasn't a viable set in totality by the art team
[08:58] <klepas> or Tangerine (as we must first see the Human icons to use the visual metaphors in the subsequent Tangerine icon for that Human icon)
[08:59] <troy_s> lost me there.
[08:59] <klepas> Mark told me that they went for a contracted artist because the art team was disorganised
[08:59] <troy_s> klepas:  bingo!
[08:59] <klepas> oh, sorry
[08:59] <klepas> i'll rephrase that
[08:59] <troy_s> that's my take on the whole situation... mark just steps up and gets the stuff done when he sees a lack of coordination.
[09:00] <klepas> Tangerine is based on Human heavily. We use their visual metaphors (ie. we copy the object Human uses in the icon for the same action)
[09:00] <troy_s> but then modify the color scheme?
[09:01] <klepas> mind you, I don't recall Mark asking us of an icon set of the like
[09:01] <klepas> not that it matters now
[09:01] <klepas> Tangerine is just as complete as Human is
[09:01] <troy_s> klepas:  see that's the problem.  NO one has bothered to put down a manifesto, nor a design doc, nor a spec listing, etc.
[09:01] <klepas> and as soon as a new Human icon comes out Tangerine is updated shortly after
[09:01] <troy_s> klepas:  IF such a thing were in place, I am pretty certain that Mark would choose the community driven effort.
[09:01] <klepas> we don't necessarily need a lot of specs
[09:02] <troy_s> klepas:  i totally disagree.
[09:02] <klepas> just friendly cooperation where people work on the things they like and allow us to get some rocking work done
[09:02] <troy_s> klepas:  structure is the key to succeeding at anything -- Ubuntu is a case in point.
[09:03] <troy_s> klepas:  it simply doesn't work well like that.  people need to know things... people need targets.  if you want to get something done, you need to define it.  this means not 'hey help us' but more "System-help in Tangerine needs completing.  Please submit your proof of principles. <vote> now work on color <vote> now work on polish etc"
[09:03] <klepas> and the Tango team are producing many icons each month
[09:04] <klepas> i like to find a middlepoint between the two extremes you just gave
[09:04] <troy_s> icons are great, and community is great, and everyone doing something is great.  THAT said, my problem with the current state (aside from there being NO art team, NO information base, NO direction, NO textural manuals, etc)
[09:05] <troy_s> is that you can't expect professional looking products (that means cohesive and truly polished) without using professional tactics.
[09:05] <klepas> Madpilot: could you explain how the doc team handles this issue?
[09:05] <troy_s> but i am willing for you to demonstrate how ubuntu's art has done wonderfully in this regard thus far.
[09:05] <Madpilot> klepas, sorry, was afk - which issue?
[09:06] <klepas> oh, just organisation... mostly in terms of how many specs and guides and so forth you have laid down
[09:06] <klepas> on how the team works
[09:06] <troy_s> let me suggest that the doc team is still evolving as well :)
[09:06] <Madpilot> not many, actually. there's already far more ArtworkTeam pages at wiki.u.c than the DocTeam has ever had
[09:07] <troy_s> mark and i have had numerous discussions about that.
[09:07] <klepas> i really like the way the doc team works personally
[09:07] <Madpilot> we had clearer-cut 'products' than ArtTeam, though - one Desktop Guide for each distro, a Server Guide, a Packaging Guide, a few stray smaller things
[09:07] <klepas> the number of guidelines and specs on how the team should work is not excessive such that people are turned away by the amount they need to read and understand before being able to contribute
[09:08] <klepas> :)
[09:08] <Madpilot> and the Kubuntu & Xubuntu Desktop Guides grew out of the Ubuntu DG after the UDG was well advanced, for the Dapper docs
[09:09] <klepas> cool
[09:09] <troy_s> klepas:  there are thus far three things listed, and those were only the ones i could realistically find in existence for the artwork team.  personally, i would like to see EVERYTHING done on the mailing list, and then posted to some sort of CMS.  simple and painless.
[09:10] <klepas> i think the wiki, mailing list, this channel, launchpad and AUC are fine
[09:10] <klepas> we need to cut down the number of pages on the wiki
[09:10] <troy_s> klepas:  if it were entirely up to me, i go to simple... too much is clutter.
[09:10] <klepas> use the ML for general communication
[09:10] <klepas> irc for chats and meetings
[09:10] <troy_s> klepas:  yep... the pages are actually _reduced_ from the amount of disorganized stuff i was compiling.
[09:11] <Madpilot> all the Ubuntu teams have this many communication channels, remember, and they manage...
[09:11] <klepas> launchpad for the formal stuff like packaging and calendar
[09:11] <troy_s> klepas:  i dislike the meetings page (useless) the agenda page (useless) etc.
[09:11] <klepas> and AUC for artwork, especially that which does not go into mainstream
[09:11] <troy_s> klepas:  i am more towards 'How to contribute' etc... with a CLEARLY listed summary of tasks.
[09:11] <troy_s> klepas:  yeah... you look into AUC by chance?  ;)
[09:12] <klepas> i have admin rights to it yes.
[09:12] <klepas> i dislike the CMS
[09:12] <klepas> greatly
[09:12] <troy_s> well ... its out of date.
[09:12] <Madpilot> our current (evolving, granted) wiki pages seem to have far too much overlap, IMO, and too many blank pages with no current purpose - vast blank pages with ambitious titles serve only to intimidate...
[09:13] <troy_s> Madpilot:  which ones?  ArtworkTeam or Artwork?
[09:13] <klepas> i suggested using something like gnome-look.org but it seems to be proprietary
[09:13] <klepas> Madpilot: agree
[09:13] <troy_s> Artwork and ArtworkTeam, might I note, were originally dumped into the hands of Henrik (once again)
[09:14] <troy_s> I did as much thinning as I dare before risking being a defacer :)
[09:14] <Madpilot> troy_s, the team pages, mostly, but they seem to be growing together somehow
[09:14] <troy_s> believe me, I am massively into quickly scannable and intuitive page organization.
[09:14] <klepas> that would be something to add to the agenda
[09:14] <troy_s> see the thing is ... it is great to have ideas, but if NO one puts them to work, they are fodder.  which is why i support Et 100% thus far for at least ATTEMPTING to move the wiki forwards.
[09:15] <troy_s> he bothers to put the legwork in when others simply don't, and for that, he should be commended.  Look how long it took for someone to step up and collect the mailing list details as requested.
[09:15] <klepas> the wiki is important to keep
[09:15] <troy_s> simple things, but it took ages to get people to DO THE WORK.
[09:15] <klepas> because it ties in with all the other things already on it
[09:15] <troy_s> its a mess.
[09:16] <klepas> then let's fix it
[09:16] <klepas> i can do it in a weekend
[09:16] <troy_s> hell the root page had NO information on how the hell to get involved with the artwork team.
[09:16] <troy_s> klepas:  uh yah.  that is why et has been posting to the mailing list.
[09:16] <troy_s> klepas:  the response is ...
[09:17] <troy_s> everyone needs to work together... i think we can all agree that while the wiki isn't great -- it took a bit of a shake up to admit that most people agree it isn't great.
[09:17] <troy_s> agree?
[09:17] <klepas> i have an idea in this regard
[09:18] <klepas> there is no point arguing endlessly how a team should function but rather after this meeting, specifically after the artist-in-chief and some art-leaders are elected
[09:18] <klepas> the leaders will fix some of the problems (such as the wiki)
[09:18] <troy_s> klepas:  which makes me a _little_ leery.
[09:19] <troy_s> klepas:  only because i suspect that mark has been waiting quite a while for this to come to a hilt and now it appears that he does indeed have a few ideas on things...
[09:19] <klepas> and if people disagree how it is ends up they can make suggestions, but otherwise unless the problem is critical or illogical we leave it
[09:19] <klepas> and fix it later
[09:19] <Madpilot> troy_s, I do agree - it's only after parts of the wiki started expanding exponentially that I realized what a mess it was ;)
[09:19] <klepas> that we can get some work done
[09:19] <troy_s> madpilot:  if you think it is expanding, you are quite incorrect... you should have seen it before i subpaged all the bits...
[09:19] <troy_s> laf.
[09:19] <troy_s> it was a nightmare
[09:20] <troy_s> still is in many respects, but as i said, slash and burn breeds dissent unless everyone agrees we need to do some burning :)
[09:20] <Madpilot> troy_s, good point - docteam had stuff spread all over the wiki until a few months ago too (which reminds me, I need to fix up the Canada Loco Team pages - same problem there...)
[09:20] <troy_s> and then there was that *uggh* split between artwork / artworkteam / art this/ art that art dapper propositions my proposition and mine and this one is really good too and god.
[09:20] <klepas> as for leadership...
[09:21] <troy_s> which is ultimately in a document stating DO THIS... DONT DO THIS.
[09:21] <klepas> three art-leaders and an artist-in-chief
[09:21] <klepas> sound cool to you?
[09:21] <klepas> that is what mark suggested.
[09:21] <troy_s> hence the template, an attempt to coordinate the means of communicate, etc.  slow but surely.
[09:21] <klepas> and people generally seem to like it
[09:21] <troy_s> sounds great to me, but tough to arrive at.
[09:21] <klepas> i think we'll manage
[09:21] <klepas> we shall see at the meeting
[09:22] <klepas> that's what i'm there for predominately
[09:22] <troy_s> for a number of reasons, not the least of which is that i am concerned there are some latent folks who might suddenly re-emerge -- of course, if you can't keep up to date via the blasted mailing list, then maybe you shouldn't be involved.  very tough questions really.
[09:22] <troy_s> problem also is that mark will not attend that one, which means the official stamp that so many people need isn't there.
[09:22] <troy_s> agree?
[09:23] <klepas> ah well
[09:23] <troy_s> https://wiki.ubuntu.com/DocumentationTeam/Projects  -- that's a great example as an aside.
[09:23] <klepas> it should not stop us
[09:23] <klepas> i'll chair it to make sure things keep on track
[09:23] <troy_s> hey i am all for anything that gets some documented structure in place.
[09:23] <troy_s> 100% for hard fast rules.
[09:23] <klepas> i've invited some of the interested folks from the doc team to join us
[09:24] <troy_s> there are a lot of new folks who are very interested, but need some clearly set documents...
[09:24] <klepas> Madpilot: can i invite you to attend?
[09:24] <troy_s> i could forward you all the mail.
[09:24] <troy_s> but i don't think you would want to wade through them all.
[09:24] <Madpilot> klepas, the artteam meeting? I'd planned on being there
[09:25] <klepas> thanks. :)
[09:25] <Madpilot> 17th @ 1600Z/0900PDT, right?
[09:25] <klepas> yea, iirc
[09:27] <troy_s> crappers... i need to bed very soon.
[09:27] <Madpilot> likewise, I need to be up in about 5 & a half hours :|
[09:27] <troy_s> eek
[09:27] <troy_s> ditto!
[09:27] <klepas> i won't put the agenda on the wiki
[09:27] <troy_s> mad:  by the way, type 'art' into a text search at the wiki.
[09:27] <klepas> mailing list will do
[09:28] <klepas> what do you think?
[09:28] <troy_s> klepas:  wise.
[09:28] <klepas> leave the wiki at this moment
[09:28] <troy_s> klepas:  the wiki is probably going to migrate to under artwork, which does make sense...
[09:29] <Madpilot> night all
[09:29] <klepas> i might add if i have the time to the wiki
[09:29] <troy_s> of course, the guidelines need to be setup for what goes where -- hence the idea of migrating towards ONE 'incoming' area for submissions / drafts / etc.
[09:29] <troy_s> a very real serious problem is that when a member of our community steps up (such as et) and says 'please help organize', the response is nil.
[09:29] <troy_s> and everyone waits for some elusive moment to happen.
[09:30] <troy_s> klepas which is now past the point, and people are actually finally starting to do some legwork.
[09:30] <klepas> i hope that andreas and lapo are amongst the team leaders
[09:31] <troy_s> andreas and lapo need to get more active.
[09:31] <klepas> ugh...
[09:31] <klepas> they work on Tangerine
[09:31] <klepas> they made it happen :)
[09:31] <klepas> they are very active... just not happy with the way the discussions are happening
[09:31] <klepas> which is why they are interested in this coming meeting so we can stop discussing and arguing and get work done
[09:34] <troy_s> well, as i said, it is very difficult to run a chess game with everyone playing their own moves.
[09:34] <troy_s> the arguing is inevitable... i just ignore it.
[09:34] <troy_s> discussions don't arrive at anything unless there is a clearly defined set of documents produced either.
[09:34] <troy_s> nobody has even bothered to look into the tools available to us.
[09:35] <troy_s> and by active i don't mean producing more, i mean simply working on structure.
[12:14] <lapo> g'morning
[12:16] <klepas> moin lapo
[12:16] <lapo> ciao klepas, how do you do?
[12:17] <klepas> doing alright
[02:31] <klepas> moin
[03:00] <troy_s> greetings lapo
[03:00] <lapo> ciao troy_s
[03:01] <klepas> the agenda has been posted
[03:26] <troy_s> klepas:  for future ref, i would suggest that plaintext is a little more standard -- if anyone is set to html off they are going to get html based distractions in the mail -- losing the gist of the message.
[03:27] <klepas> mhh
[03:28] <klepas> right
[03:28] <klepas> i was tossing it up
[03:28] <klepas> i wanted to bring attention to various things
[03:28] <klepas> and if they use evolution/sylpheed/kmail they ought not have any problems :)
[05:41] <qmf> hey guys, is there a package with the ubuntu logo's avaiable for download?
[05:47] <lapo> qmf: check here: http://www.ubuntu.com/ubuntu/TrademarkPolicy?highlight=%28logo%29
[05:48] <qmf> fantastic. thanks
[05:49] <lapo> np
[07:05] <qmf> i submitted a background.. how long does it take to be accepted?
[07:13] <adamant1988> no idea
[07:13] <adamant1988> I submitted a couple yesterday and the day before
[07:13] <adamant1988> can I see the wp you submitted?
[07:18] <lapo> qmf: accepted?
[07:26] <qmf> http://starqmf.com/images/smoke001
[07:26] <qmf> lapo - it's pending at the moment
[07:26] <lapo> qmf: where? art.ubuntu.com?
[07:27] <qmf> yeah
[07:30] <adamant1988> qmf did you paint that with fractal brushes?
[07:33] <adamant1988> ??
[07:36] <qmf> no, i was pretty stoned one night and was taking pictures of smoke in a projector beam
[07:37] <adamant1988> that explains a lot
[07:37] <qmf> heh
[07:38] <qmf> i have 2 gigs worth of them
[07:38] <qmf> need to sort through and find the good ones
[07:38] <adamant1988> word of advice... try to not saturate them as much.
[07:57] <qmf> i didn't touch the photo, it's as it was taken, xcf is with it tho so people will be able to desaturate if they fancy that.
[08:05] <adamant1988> are there any artists/designers in here who might want to do a collaberation for an Ubuntu WP?
[09:01] <qmf> ahh, photoshop 7 under ubuntu. now i can be productive!
[09:01] <adamant1988> how did you get ps7 working?
[09:01] <adamant1988> wine?
[09:02] <qmf> crossover office
[09:02] <qmf> works perfect
[09:02] <adamant1988> ah, how much does that run?
[09:02] <adamant1988> the price I mean?
[09:02] <qmf> .. i didn't pay for it so i dont know
[09:03] <adamant1988> you jacked a copy of crossover?
[09:03] <qmf> yes.
[09:03] <adamant1988> tsk tsk
[09:03] <adamant1988> I want to see some of your work though
[09:03] <qmf> i'm a chef in a pub kitchen. i can't afford to throw money away on things that should be open source in the first place
[09:13] <qmf> im gonna read up on some gnome theme tutorials
[09:13] <qmf> they look pretty tough
[09:14] <adamant1988> do you have any finished works I can see?
[09:14] <qmf> of what?
[09:14] <adamant1988> art
[09:14] <qmf> my last webhost went down with all my stuff on it.
[09:14] <qmf> i have backups on a box which is in storage
[09:14] <adamant1988> so you don't have ANYTHING you can show me?
[09:14] <qmf> so i can't really get anything off there right now.
[09:15] <qmf> no, i literally turned this laptop on for the first time in months 3 days ago
[09:15] <qmf> oh
[09:15] <qmf> no wait
[09:15] <qmf> http://starqmf.deviantart.com
[09:16] <qmf> forgot about that


 https://kubuntu.org/news/plasma-5-19-testing-in-groovy-gorrila/
 https://twitter.com/kubuntu/status/1277978377815646208
 Sweet 😃
[19:01] <valorie> @RikMills: did you send that to the lists already?
[19:01] <valorie> if not, I will
 I have not yet to the mailing lists
[19:09] <valorie> on it
[19:20] <valorie> I sent it out and then noticed that the link has gorila instead of gorilla
[19:20] <valorie> however it is correctly spelled in the headline and story so whatever
 Yeah, I saw that too late!
[19:26] <valorie> https://www.kubuntuforums.net/showthread.php/77036-Plasma-5-19-testing-in-Groovy-Gorilla?p=438561#post438561
[19:26] <valorie> we're probably the only ones who will notice
[19:26] <valorie> :-)
[19:27] <valorie> I'll ask kde-promo to RT


[00:07] <kelvin> hi wallyworld im here
[00:07] <wallyworld> ah, different nic?
[00:08] <wallyworld> have you pushed changes to charm.v6?
[00:08] <kelvin> ah.. let me change it!
[00:11] <kelvin> wallyworld, can i have ur a few minutes on HO?
[00:12] <wallyworld> sure
[00:43] <kelvin> hi wallyworld do u think the `devices` will be used for GPU only or could be something else in the future?
[00:43] <wallyworld> whatever k8s supports, like networks cards etc
[00:44] <wallyworld> that's why we wnet with the generic "devices" name
[00:44] <wallyworld> but for now, initially, just gpu
[00:44] <wallyworld> there's a link in the spec to the k8s device plugin framework
[00:45] <kelvin> so I define the Device.Name -> nvidia.com/gpu and Device.Type -> gpu.
[00:46] <kelvin> Is this correct?
[00:46] <wallyworld> no, define name is somthing meaningful to the charm
[00:46] <wallyworld> like "bitcoin-miner"
[00:47] <wallyworld> type is either "gpu" or "nvidia.com/gpu"
[00:47] <wallyworld> depending on if the charm wants just a generic/any gpu or specifically an nividia one
[00:47] <wallyworld> there are examples in the spec
[00:48] <wallyworld> initially we'll probably do an exact match on charm metadata device type and k8s
[00:49] <kelvin> ok, got it. thx
[01:54] <anastasiamac> wallyworld: when u r bored and wonder what to entertain ur mind with, could u PTAL at https://github.com/juju/juju/pull/8834
[01:54] <wallyworld> lol, bored
[01:55] <anastasiamac> this is the last part before storage interface :D and actual providers changes ...
[01:55] <anastasiamac> lol, i know :D
[02:10] <wallyworld> anastasiamac: done
[02:12] <anastasiamac> wallyworld: thnx \o/
[02:13] <anastasiamac> wallyworld: F vs Func... one the type, the other the name of the variable...
[02:14] <wallyworld> i see, ok. we tend to use Func for var names elsewhere, but i'm not too worried about that one. the names just grated a bit
[02:14] <anastasiamac> wallyworld: but, yes, consistency is better and Func everywhere is more explicit
[02:14] <wallyworld> i had hungarian notation flashbacks
[02:15] <anastasiamac> wallyworld: agree :) func is better :) i'd even go with 'funk' but m sure it won't b liked either :)
[02:15] <wallyworld> yes! funk!!!!!
[02:16] <anastasiamac> :D
[02:16] <wallyworld> anastasiamac: there's an F on the context as well i think? could do that as a drive by?
[02:16] <anastasiamac> wallyworld: k...
[02:17] <anastasiamac> but u do know that there r a few Fs in the codebase :)
[02:34] <wallyworld> no, didn't know
[02:47] <anastasiamac> here is one (altho in tests so probably does not count as much... but still exists...) https://github.com/juju/juju/blob/develop/cmd/juju/commands/bootstrap_test.go#L2056
[02:53] <kelvin> wallyworld, I just moved the Count Validation from Checker to `schema`, and addressed all the other comments, would you mind to take another look? thanks.
[02:53] <wallyworld> sure
[03:11] <wallyworld> kelvin: lgtm but we need to drop the checks for specific device type values, see my comments
[03:12] <wallyworld> the schema should just be to check that a value is supplied
[03:12] <kelvin> wallyworld, yes, looking now
[03:12] <wallyworld> juju should validate the actual values based on capability of the cloud
[03:12]  * wallyworld off to vet for a bit
[03:15] <kelvin> wallyworld, yes, u r right, we will have to do more detailed checks later on juju side based on the runtime status of the cluster, so here we do not need to validate the type value.
[04:46] <wallyworld> kelvin: that should be good to land, just go ahead and $$merge$$
[04:47] <wallyworld> then you can pull tip of master locally and do the deps update
[04:47] <kelvin> wallyworld, yes, doing it now, thx
[06:57] <anastasiamac> wallyworld: storage signatures change to accomodate call context... PTAL when u can - https://github.com/juju/juju/pull/8835 :D
[08:03] <wallyworld> anastasiamac: looking
[08:04] <anastasiamac> wallyworld: it's not fully ready yet - i need to fix storage provisioner worker, etc... most of logic is there tho... wip :)
[08:04] <wallyworld> i'll wait till done
[08:06] <anastasiamac> k
[08:58] <KingJ> BlackDex: Sorry I missed your reply!
[08:58] <KingJ> BlackDex: ip ro get shows me a single route using a matching interface and gateway
[09:00] <BlackDex> very strange indeed then that it doesn't work. That interface is the same interface the requests does its ingress on?
[09:00] <KingJ> BlackDex: What i'm thinking though is that only one of these network spaces should have a gateway defined to prevent this issue - that way it's always consistent. But i'm not sure which 'space' is best for this, none of the charms share a common space - and presumably each charm needs at least one space with a gateway in order to hit apt etc?
[09:01] <BlackDex> KingJ: Or just use the apt-proxy
[09:01] <BlackDex> from juju
[09:01] <BlackDex> i have build several environments which them selfs don't have internet access at all
[09:01] <KingJ> apt-http(s)-proxy?
[09:01] <BlackDex> yea, and no dfgw
[09:02] <KingJ> I have that defined already, but to a value that isn't part of the network spaces - how will it be able to route there? using the system level default gw?
[09:03] <BlackDex> routing is not available then
[09:03] <BlackDex> thats true
[09:03] <BlackDex> maybe your network setup is to complex for what i suggest
[09:03] <KingJ> Hmm, would you have an example diagram of one of these environments?
[09:03] <KingJ> I'm always able to make changes ;)
[09:04] <KingJ> It sorta sounds like I need to remove the default gateway from each of the space subnets, but make sure each charm also has access to a common space that contains a proxy, and set apt-http-proxy to that host.
[09:05] <BlackDex> they are very simple. Just one network for openstack communication, and a pxe network for the systems. Some containers do not have the pxe network, but do have the apt-proxy stuff. and the maas node has an interface in both networks as does juju
[09:06] <BlackDex> that way juju can still communicate with all the charms. Also the juju controller uses the maas proxy!
[09:07] <KingJ> Ahh I see. Mine's broken up in to about 7 spaces similar to this... http://blog.naydenov.net/wp-content/uploads/2015/11/openstack-spaces-e1447000706196.png
[09:07] <BlackDex> via the `juju model-config -m controller` settings
[09:07] <KingJ> (which to be fair, does have internal-api as a common space across all charms which i've not done, hmm, that could be the fix...)
[09:09] <KingJ> Although ceph-osd and ceph-mon don't have a binding to anything other than storage and storage-cluster in the charm, I think I could use extra-bindings to give it an address in the internal-api space too, which would mean all my charms have a binding there and I could use that as my proxy subnet.
[09:10] <BlackDex> ah yes, that is the only thing i do have, a separate storage network indeed :)
[09:10] <BlackDex> and that is only connected to the charms which need it
[09:11] <KingJ> How have you connected that seperate storage space for proxy access?
[09:12] <BlackDex> not, because ceph-osd and ceph-mon are connected to the interal ;)
[09:12] <BlackDex> and maas has a nic in the internal also to provide the proxy
[09:12] <KingJ> Ahhhh
[09:12] <KingJ> So you've bound your ceph-* charms to internal and a dedicated storage network?
[09:13] <BlackDex> yes!
[09:13] <BlackDex> just be sure to correctly configure the bondings or the *network* config options
[09:13] <BlackDex> that messes stuff up for me sometimes
[09:14] <BlackDex> for the bondings in a bundle see: https://github.com/openstack-charmers/openstack-bundles/blob/master/development/openstack-base-spaces/bundle.yaml
[09:24] <KingJ> BlackDex: That's a useful bundle reference. I'm trying to work out how best to bind it to my internal now. I've already got public -> storage-data and cluster -> storage-cluster, so I need to pick something for internal.
[09:24] <KingJ> I'm not sure how to 'discover' what bindings a charm supports though. So for example, ceph-osd's metadata.yaml lists bindings of 'public' and 'cluster' (https://github.com/openstack/charm-ceph-osd/blob/master/metadata.yaml) but the juju error output implies it supports bindings of "admin", "bootstrap-source", "client", "cluster", "mds", "mon", "nrpe-external-master", "osd", "public", "radosgw"
[09:25] <KingJ> Where are those extra bindings defined?
[09:28] <BlackDex> haha, i did a dirty trick to get all those
[09:28] <BlackDex> a long time a go
[09:28] <BlackDex> i just added a non-existing bond
[09:29] <BlackDex> like 'foobar'
[09:29] <BlackDex> then juju returned me an error telling me which were available
[09:30] <BlackDex> else i would have to download all the charms and look for it in the source-code, because not everything was in the metadata.yaml of the charms
[09:30] <KingJ> Ok forgive me, the link I gave to metadata.yaml was for ceph-osd, but the juju output was for ceph-mon. Now that i'm looking at ceph-mon's metadata.yaml I can see the same bindings....
[09:30] <BlackDex> they have the same :)
[09:30] <BlackDex> that is correct
[09:30] <BlackDex> you can also add a default bond btw
[09:30] <BlackDex> instead of a name use ""
[09:31] <KingJ> Will that be used in addition to defined ones?
[09:31] <BlackDex> "": space-name
[09:31] <KingJ> so e.g., ceph-osd supports bindings to public and cluster, which i've already bound. If I bind default too, will I get a third interface
[09:31] <BlackDex> yes :)
[09:32] <KingJ> perfect :D
[09:32] <BlackDex> it should as far as i know atleast
[09:32] <KingJ> which solves my problem of "ceph-osd can only bind to public and cluster and i've bound those to spaces other than internal"
[09:32] <BlackDex> but
[09:32] <BlackDex> it is better to use "constraints: spaces=space1,space2,space3"
[09:33] <BlackDex> or both ofcourse
[09:33] <BlackDex> the constaints will ensure the nic bridged
[09:34] <KingJ> So far i've been explicitly binding charms to space(s), and sounds like it's best for me to keep doing that except in cases like the ceph charms where I need an extra space that's not used by the charm's bindings, but instead by core network stuff.
[09:34] <BlackDex> i'm used to the constraints because that was in 2.x somewhere, and the bonding came later
[09:35] <BlackDex> so, i really don't know if they have the same effect actually
[09:35] <BlackDex> the bonding values are also used by the charm to configure values
[09:35] <BlackDex> like keystone uses those to configure the pub,int,admin parts
[09:35] <KingJ> I've just updated my bundle for ceph-mon to have a default binding to my internal space in addition to the existing explicit binds, deployed and I can see now they have 3 interfaces, perfect.
[09:36] <BlackDex> nice :)
[09:36] <KingJ> So now I can change MaaS to not put default gateways on every subnet, except for the admin subnet.
[09:36] <KingJ> * internal subnet
[09:37] <KingJ> so that'll result in a single default gw on all of them
[09:40] <TheAbsentOne> rick_h_ stub cory_fu zeestrat kwmonroe and all others I'm forgetting: I want to all thank you for all the help the past few months! In 20 hours I need to present my research and generic database implementation. If you guys are interested in the presentation it can be seen here: https://www.youtube.com/watch?v=DPtRJKgNxoA
[09:40] <TheAbsentOne> Let's hope things go well :fingerscrossed:
[09:41] <TheAbsentOne> (and sorry for the bad english >.<)
[10:02] <zeestrat> TheAbsentOne: best of luck!
[10:08] <TheAbsentOne> thanks!
[10:17] <anastasiamac> wallyworld:  8835 is ready for review - all unit tests pass locally
[10:18] <stub> Hmm... is 'juju deploy' preferring xenial over bionic, even for multiseries charms that list bionic first? cs:cassandra lists bionic first, but I get xenial vms unless I override with --series
[10:19] <stub> My test charm that only lists bionic as a supported series gets bionic as a default just fine
[10:20] <stub> Hmm, no. The test charm lists the exact same 3 series as supported. So the only difference I can think of is the charmstore, since older versions of cs:cassandra didn't support bionic?
[10:21] <stub> I'd be interested if other people see the same thing, with 'juju deploy cs:~cassandra-charmers/cqlsh' getting bionic and 'juju deploy cs:cassandra' getting xenial
[10:27] <naturalblue> hi guys/gals. i granted a user to a admin rights to a model. a few mins later i am getting this error "ERROR cannot log into controller "maas-controller": cannot get discharge from "https://<IP_ADDRESS>:17070/auth": cannot acquire discharge: cannot http POST to "https://<IP_ADDRESS>:17070/auth/discharge": Post https://<IP_ADDRESS>:17070/auth/discharge: proxyconnect tcp: tls: oversized record received with length 20527"
[10:28] <naturalblue> im not using any proxy between the juju client and the juju maas controller
[10:30] <naturalblue> juju controllers shows the controller but no user/access. its like it removed my access from the controller model at the same time as giving the user admin to the openstack model
[11:02] <stub> cory_fu: endpoint.{endpoint_name}.joined gets set when the first relation is made, but there is no event signaling that a second relation has been made to that name
[11:04] <stub> When two client applications are related to something like a database (ie. juju add-relation cqlsh:database cassandra:database; juju add-relation cqlsh2:database cassandra:database)
[11:13] <stub> cory_fu: https://pastebin.canonical.com/p/BwRRF8thTp/ is the relevant code, which works great for just one relation. Second relation, no new flag so no handlers in the interface or my charm get triggered.
[11:14] <stub> cory_fu: I can work around it with a @hook
[11:25] <stub> Hmm, I also can work around it by watching for endpoint.{endpoint_name}.changed.private-address, which I can reset
[11:32] <stub> practical fix might be for clear and set the endpoint.{endpoint_name}.{joined, changed.*} flags when a new relation appears, which a trigger can react to.
[11:33] <rick_h_> TheAbsentOne: you can do it!
[11:35] <rick_h_> naturalblue: hmm, what command did you use to grant access?
[11:36] <TheAbsentOne> Let's hope rick_h_!
[11:44] <stub> But I think a new endpoint.{endpoint_name} flag will be better, if we can think of a suitable name
[12:01] <naturalblue> rick_h_: juju grant <username> admin openstack (openstack is model name)
[12:02] <rick_h_> naturalblue: ok, and can you still run show-model on the openstack model?
[12:04] <naturalblue> rick_h_: ERROR refreshing models: no credentials provided (no credentials provided)
[12:04] <rick_h_> naturalblue: can the other user run the command?
[12:05] <naturalblue> rick_h_: i am both users
[12:05] <naturalblue> 1 is admin and 1 is naturalblue
[12:05] <rick_h_> naturalblue: ah ok, from the same terminal?
[12:05] <rick_h_> or machine I guess
[12:05] <naturalblue> when i try to login with either user is get
[12:06] <rick_h_> naturalblue: so...you ran the register command on that machine and gave the controller a new name?
[12:06] <naturalblue> no
[12:07] <naturalblue> i was logged into the maas-controller on the client machine
[12:07] <naturalblue> i ran the juju grant naturalblue admin openstack
[12:07] <naturalblue> after a minute or 2 i started getting the proxy error
[12:08] <naturalblue> i logged out and tried to login as both users and am still getting the same message
[12:08] <rick_h_> naturalblue: ok, bear with me. Having my morning coffee still. There's some cached files in .local/share/juju that have the admin credentials in them normally.
[12:09] <rick_h_> I'm wondering if they got confused but if you ran register on another machine it shoudn't have.
[12:09] <naturalblue> sorry, i wasnt giving out, just giving a better recap. i will check now
[12:09] <rick_h_> naturalblue: can you run juju commands from the maas-controller then?
[12:09] <rick_h_> naturalblue: as the new user?
[12:14] <stub> cory_fu: Oh, I guess endpoint.{endpoint_name}.changed is what I am supposed to hook into, and that will work fine. I don't know why it took me so long to get there :)
[12:18] <naturalblue> rick_h_: i will see about loggin into the maas-controller now
[12:18] <rick_h_> naturalblue: k, I wanted to see if it's working on that end and we can probe the model for details to make sure the access is still there for everyone
[12:20] <naturalblue> ^^ i still have access to the openstack model for naturalblue in the juju gui
[12:23] <naturalblue> rick_h_: when i try to ssh to the maas-controller it says permission denied
[12:23] <naturalblue> i have tried with admin and naturalblue. it does even get to a password prompt
[12:23] <naturalblue> the controller was setup using juju
[12:23] <rick_h_> naturalblue: is maas deployed with juju or something?
[12:23] <rick_h_> naturalblue: I mean juju sits on top of maas
[12:23] <rick_h_> naturalblue: so I'd expect you to be able to ssh to that machine from wherever you set maas up
[12:25] <naturalblue> i setup the maas-controller from the maas region server. i am on that now as i use it for juju client actions. it is the system i am getting the errors from when i try to ruin juju commands
[12:26] <naturalblue> i setup a maas region controller, then installed juju, from that deployed a juju-maas-controller on a different machine. I then setup a naturalblue user. i added an openstack model. i deployed my openstack setup to other machines. i then granted naturalblue admin access to the openstack model. This is where i am now
[12:27] <naturalblue> all actions where done a the defult setup admin user.
[12:27] <naturalblue> after i granted the naturalblue user admin access to openstck model, i have lost access to everything it seems
[12:28] <naturalblue> as both admin and naturalblue
[12:28] <naturalblue> although in the juju gui i had open for naturalblue, i do have the openstack model there and can do things
[12:28] <naturalblue> strange!
[12:33] <KingJ> You can force a charm to deply on a non-supported series via the juju CLI - how would you do that in a bundle configuration?
[12:49] <rick_h_> KingJ: we don't have a --force in the bundle atm
[12:50] <KingJ> rick_h_: Ah I see. For now, i'm working around it for the moment by deploying with force on the CLI, then using the bundle to configure and relate.
[12:52] <rick_h_> KingJ: yea, the --force was meant really so folks could test/etc before things got updated but not something you'd want to do in prod with a repeatable bundle
[12:52] <rick_h_> KingJ: at that point it's best to edit the charm and push the update
[12:53] <KingJ> rick_h_: Yeah, understandable that that is the preferred approach. Unfortunately this is a charm from the store that hasn't yet been updated with bionic support in the manifest, even though it does work fine on bionic.
[12:54] <rick_h_> KingJ: gotcha, have you filed a bug on the charm? Should be a link to file bugs if the charm author set a homepage/bugs-url
[12:54] <KingJ> rick_h_: I did yeah, although unfortunately there's been no traction on the bug since I filed it 3 weeks ago.
[12:54] <KingJ> I wouldn't mind making the changes myself - if I forked it can I publish it to the store too? (albeit under my username instead of theirs?)
[12:55] <rick_h_> KingJ: bummer, what charm?
[12:56] <rick_h_> KingJ: exactly, you can use the charm cli tool to pull down the charm, edit it, and push to your own space
[12:56] <KingJ> rick_h_: https://jujucharms.com/u/bertjwregeer/snmpd/3
[12:56] <KingJ> rick_h_: Ah cool, I will look in to doing that in the mean time then
[12:56] <rick_h_> KingJ: https://docs.jujucharms.com/2.3/en/authors-charm-store
[12:57] <KingJ> rick_h_: Perfect, thanks for the information and pointers :)
[13:19] <cory_fu> stub: .changed will work, certainly.  I do think that .joined should re-trigger on new units, but that touches on the idea that I think all handlers / triggers should be edge-triggered and there should be an explicit mechanism for forcing an edge (which, under the hood, would just clear / set cycle the flag).  But I was already writing up a more in-depth discussion of that for https://github.com/juju-solutions/charms.reactive/issues/177
[13:24] <cory_fu> stub: Also, your usage pattern for the endpoint is very different than what I usually recommend, in that you're using the relations collection outside the endpoint class.  It seems like a pretty natural way of doing it but it breaks encapsulation somewhat, mainly because the endpoint class can't influence the relations list, leading to things like your `publish_credentials(rel, False)`.  I wonder if it would be a good pattern to allow the endpoint
[13:24] <cory_fu> class to provide a subclass implementation for Relation and Unit so that those collections could be used directly with the interface layer being able to extend them like it can the Endpoint, so that we don't have to pass around rel_id or some other synthetic ID?
[13:30] <stub> cory_fu: This is a peer relation, which have a tendency to break encapsulation
[13:32] <stub> I would like to move stuff into the endpoint peers.py, but this was the first pass through translating things to reactive
[13:36] <stub> cory_fu: The Endpoint implementation can already override the relations property to return wrapped relations and access to wrapped units, with effort.
[13:38] <stub> cory_fu: I wouldn't bother with making things pluggable, at least at this stage. I think it would likely make things more confusing for people with more normal use cases.
[13:41] <stub> https://pastebin.ubuntu.com/p/YXBBVMXcD4/ is the full client.py file, which certainly could all be moved to provides.py. Encapsulated, just not where you expected it ;)
[13:50] <stub> And yes, I'm confusing two bits of code in my head and realise this is not a peer relation
[13:52] <stub> But in general I'm finding the client side easy to publish as an interface, but the server side implementation seems easier this way.
[14:00] <cory_fu> stub: The server side is always going to feel easier to write that way, but the issue is that it makes it harder for others to create an interface-compatible server, since they have to make sure they re-implement the interface data protocol properly, probably by reading code.  The purpose of the provides side is to provide a documented API for anyone who wants to support the same interface.  Of course, that's not going to happen very often, so it
[14:00] <cory_fu> feels like pointless work.  :p
[22:48] <thumper> morning peeps
[23:54] <wallyworld> kelvin: reviewed - there's a dependency issue, see if my comments make sense
[23:55] <kelvin> wallyworld, looking now, thx


[18:21] <smoser> harlowja_away, around ?
[22:43] <natorious> trying to get cloud-init running on Gentoo
[22:43] <natorious> there appears to be a package in portage but installing it doesn't provide any init scripts
[22:44] <natorious> would copying the rhel init scripts be all thats needed?  Anything else I might run into?
[23:01] <pquerna> smoser: cla thing is recorded.