[00:59]  * Pici is stuck in class
[01:00]  * Fujitsu wonders if the `IRC Council Calender: http://fridge.ubuntu.com/event' meeting is a new one, or if somebody forgot a pipe.
[01:00] <Pici> Someone forgot a pipe
[01:01] <Pici> Probably Seveas
[01:01] <PriceChild> Right so I'm here, and nal and lj.l waiting on elky I think.
[01:03] <LjL-Temp> i'm here, i think, perhaps
[01:03] <LjL-Temp> as soon as i can get my nickname
[01:04] <PriceChild> The agenda is at https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda as always.
[01:05] <Seeker`> *cough*Mootbot*cough*
[01:06] <AndrewB> Good afternoon.
[01:06] <Pici> Is it possible to go over the offtopic stuff first? my time is short here.
[01:06] <PriceChild> Right cool so lets get started.
[01:06] <PriceChild> I don't see why not if the others are ok with it?
[01:07] <PriceChild> Pici, You aren't Mr Rubin are you?
[01:07] <Pici> PriceChild: I happen to be Mr. Rubin.
[01:07] <Pici> I need a wiki page ;)
[01:07] <elkbuntu> yeah... im trying to find the agenda too
[01:08] <Pici> elkbuntu: https://wiki.ubuntu.com/IrcTeam/IrcCouncil/MeetingAgenda
[01:08] <Pici> I think that we need to document the rules for offtopic in the Wiki and provide a link to it in the channel topic, much like we do with the IRC guidelines for #ubuntu.
[01:08] <elkbuntu> Pici, i should know that. i made the page :Þ
[01:08] <PriceChild> Pici, do the current guidelines not work?
[01:09] <LjL> Pici, please note that the Ubuntu guidelines are valid in *all* channels, and they don't go too much into the specifics even for #ubuntu -- The specifics are mostly handled using bot factoids, same as in #ubuntu-offtopic
[01:09] <LjL> Guidelines are guidelines, they aren't (or shouldn't be) a very detailed list of rules
[01:10] <Pici> PriceChild: I'll be honest, I read over the guidelines a few times and didnt see the o4o stuff.  Of course right now I just looked at it and saw it immediately.
[01:10]  * Pici smacks forehead.
[01:10] <elkbuntu> the o4o should be constantly revised anyway
[01:10] <AndrewB> Umm o4o means?
[01:10] <LjL> AndrewB, "offtopic for offtopic"
[01:10] <LjL> !o4o
[01:10] <ubotu> Some things are inappropriate for #ubuntu-meeting. Controversial topics, which always turn into flamewars: war, race, religion, politics (unless related to software licencing), gender, sexuality, drugs, questionable legal activities, removing of oneself from the planet (except by space or time travel) are not for here, perhaps #off-topic or ##politics. Microsoft software in ##windows (Please note Freenode Policy) - Thanks.
[01:10] <elkbuntu> additionally, offtopic shouldnt be touted as a channel for 'anything and everything'
[01:10] <AndrewB> oh
[01:11] <Seeker`> offtopic 4 offtopic?
[01:11] <Pici> Anyway. I added the guidelines to the topic (which werent there).  Even though the offtopic topic is fun, and changing, we should make it a policy to always keep that link there.
[01:11] <PriceChild> Is there something in Guidelines about taking heed of bot factoids where appropriate? *looks*
[01:12] <PriceChild> Maybe that would be good? I'm pretty sure I've had a few complaining to me that they didn't think they have to abide by what the bot says seen as it doesn't say that in the guidelines.
[01:12] <LjL> Pici, we used to have "/msg ubotu o4o" in the topic, too, but you know that topic changes quite often. In any case, the guidelines should contain general concepts that can be *implemented* by us; so, if you think the guidelines lack something (i.e. !o4o isn't, for example, a valid implementation of "Be respectful"), then that would be a valid concern.
[01:13] <LjL> PriceChild, I suggest that we discuss that later, on the "Possible revision of the guidelines" item, as I had something much like that in mind.
[01:13] <PriceChild> k cool
[01:13] <Pici> LjL: I rescind my original Agenda item.  I somehow skipped the o4o section of the guidelines.
[01:13] <PriceChild> Ok cool.
[01:13] <Pici> Twice.
[01:14] <PriceChild> hey i said that twice...
[01:14] <PriceChild> anyway next item then :)
[01:14] <LjL> Which one shall we next?
[01:14] <elkbuntu> the top one i think
[01:14] <PriceChild> I say 3... as 1,2,4 are linked
[01:14] <PriceChild> and 3's related to this
[01:15] <elkbuntu> good point
[01:15] <LjL> Ok
[01:15] <Pici> Okay.
[01:15] <LjL> I propose that the guidelines might be in need of *slight* revision. Specifically, we should:
[01:16] <LjL> 1) Clarify what kinds of "advice" are welcome. "Good advice" and "bad advice" can be subjective concepts, and I believe we should make it clear in the guidelines that "bad advice" is worse than no advice, and define "bad advice" as something specified by the operators, which on their turn get it from Canonical support staff, and ultimately from the Ubuntu Technical Board
[01:25] <Pici> aer
[01:25] <Pici> PriceChild: ignore me, I can't read.
[01:25] <elkbuntu> Pici, we're beginning to notice :Þ
[01:25]  * Pici smacks forehead again
[01:25] <LjL> PriceChild: Sure, it will be put in a softer way than I put it here. In the end, though, it comes down to the fact that we CAN state that a certain kind of action is unsupported and should NOT be recommended, and helpers should respect that.
[01:26] <PriceChild> yup
[01:26] <LjL> I think we can come up with a proper wording for that, but I think the concept behind it is clear to us.
[01:26] <Seeker`> if people think that they haven't done anything wrong, they wont care if a factoid says that ops can decide what is/isnt bad behaviour / advice though
[01:27] <PriceChild> I would hope that the CoC's being responsible for your actions would cover this but of course trolls have selective vision...
[01:27] <LjL> Not a factoid, Seeker`, I'm talking about putting this in the *Guidelines*. Then there can be, perhaps, specific factoids about things that are unsupported
[01:27] <elkbuntu> PriceChild, most people dont get the !worksforme concept
[01:27] <elkbuntu> s/most/many/
[01:28]  * Pici agrees
[01:28] <LjL> And if they do, they maintain the opinion that they should still be allowed to give advice that "works for them", since they're volunteering to give that advice.
[01:28] <LjL> But I don't believe that is the mindset that we encourage in the channels.
[01:28] <elkbuntu> of course it's not
[01:30] <Pici> !ping
[01:30] <ubotu> pong
[01:31]  * Pici watches a tumbleweed roll by
[01:31] <Jucato> the meeting's over?
[01:31] <elkbuntu> no
[01:31] <LjL> "While we encourage everyone to offer Ubuntu support to other users, it is the channel operators' duty to ensure that the advice given is sound and safe, and operators will use their best judgment to ensure that the channel as a whole follows the recommendations of the Ubuntu Technical Board"
[01:31] <elkbuntu> everyone's just off reading/scribing stuff
[01:32] <Pici> I thought I got lagged out, sorry.
[01:32] <LjL> is there agreement on this specific text - if we need to lay out the precise text right now - for my point 1?
[01:40] <LjL> can we go on without logging and users coming and going?
[01:40] <elkbuntu> LjL, surely someone here is logging (i know i am) and we can pass on the logs to scribes
[01:40]  * Seeker` suggests using mootbot to log stuff as well
[01:40] <elkbuntu> Seeker`, mootbot isnt immune from splits either
[01:40] <LjL> elkbuntu: I suppose so, and our logs can be cross-checked if anyone asks that...
[01:40] <Seeker`> elkbuntu: I know, but it is another logging source
[01:40] <elkbuntu> lets continue before another one hits
[01:41] <LjL> so, please, elkbuntu, nalioth, PriceChild, can we consider that point #1 approved, and perhaps the latest text I posted acceptable?
[01:41] <AndrewB> If needs be I can provide a log.
[01:41] <PriceChild> Yeah I think I'm happy with that.
[01:41] <elkbuntu> LjL, point one approved, point two subject to a little more revision
[01:42] <nalioth> approved, subject to fine tuning
[01:42] <LjL> Ok, for point #2 I propose the following text:
[01:42] <LjL> "These guidelines do not cover every single aspect of the Ubuntu channels' etiquette. Specific practices are encouraged and discouraged, according to these guidelines' intent as well as to practical channel needs. Recommendations from channel operators, including those stored in the channel bots, should be followed."
[01:43] <elkbuntu> wasnt there more?
[01:43] <LjL> More of what, elkbuntu?
[01:44]  * elkbuntu shrugs
[01:45] <LjL> elkbuntu, explain yourself, I'm simply not following you :-)
[01:45] <elkbuntu> LjL, what point is this for? #3 on the agenda?
[01:46] <LjL> No elkbuntu, still "Possible revision of the guidelines" (listed as third)
[01:46] <LjL> I meant the second part that I proposed about that
[01:46] <LjL> I will summarize again
[01:46] <elkbuntu> ah, right, i was confused at why it changed completely from your last bit
[01:47] <LjL> 1) Clarify what kinds of "advice" are welcome. "Good advice" and "bad advice" can be subjective concepts, and I believe we should make it clear in the guidelines that "bad advice" is worse than no advice, and define "bad advice" as something specified by the operators, which on their turn get it from Canonical support staff, and ultimately from the Ubuntu Technical Board
[01:47] <LjL> This was approved
[01:47] <LjL> 2) Clarify that the guidelines don't codify EVERY rule that is applied in #ubuntu and other channels, but, as we were saying now, just the... guidelines. So, we should point out in the guidelines that operators can (through the bot) give useful indications to people, and that those should be respected
[01:47] <LjL> The point above is what the text I proposed now would refer to
[01:47] <elkbuntu> ah right. +1. i think everyone else is mia though
[01:48] <LjL> PriceChild, nalioth?
[01:48] <nalioth> yes
[01:48] <PriceChild> Nope I'm happy I think :)
[01:48] <nalioth> yes +1 agreed
[01:49] <LjL> Then can we move on to... which item?
[01:49] <elkbuntu> LjL, back to the top i think
[01:49] <PriceChild> number 1?
[01:49] <elkbuntu> LjL,  it precursors #2 imho
[01:50] <LjL> They're certainly interwa... however it's said. Connected.
[01:50] <PriceChild> i'll start 1 :P
[01:50] <PriceChild> https://wiki.ubuntu.com/IrcTeam/Scope & https://edge.launchpad.net/~ubuntu-irc are the only two pages currently describing the ubuntu-irc team afaik.
[01:50] <LjL> "Clarification of what the "ubuntu-irc" team actually is and who is eligible to join" and "Clarification on the status of #ubuntu-ops, who may idle, who gets voice"
[01:51] <elkbuntu> we should clarify who is part of the team before we decide who is eligable to be in there
[01:51] <PriceChild> Despite the "Only existing operators should join this team" we've had lots of applications to the ubuntu-irc team lately, most not replied to yet. Almost all from "random" people who don't op in many channels I'm familiar with, and who don't frequent the main help channels either.
[01:51] <PriceChild> I'd just like to flesh out those two pages, describe better what this team is for and who's eligible to be a member.
[01:51] <somerville32> I thought the "no one but ops in -ops" attitude was abolished
[01:51] <LjL> somerville32, let's start with the Ubuntu IRC team for the moment.
[01:52] <somerville32> LjL, sorry
[01:52] <PriceChild> https://wiki.ubuntu.com/IrcTeam/Scope is a little unsure of itself and seems to say that operating in a #ubuntu channel and being in ubuntu-irc is one and the same.
[01:52] <elkbuntu> somerville32, it is, but we also have a high rate of trolls and botnet people lurking in there being disruptive
[01:52] <PriceChild> What has been the case so far afaik, is that a helpful user gets invited to operate in a channel or two (whether by council or other contact), is observed, and hopefully eventually accepted into the ubuntu-irc team where they are in a much better position to request ops in other channels to help out further. I like this more.
[01:52] <elkbuntu> somerville32, hobbsee got attacked based on something said in there by nicks that were not in there
[01:53] <somerville32> PriceChild, Wouldn't you agree that the channels should be operated people directly related to that channel?
[01:53] <somerville32> (for the most part)
[01:54] <LjL> PriceChild, I think your proposal follows the one that was made and approved in a previous meeting, that "the Ubuntu IRC team is a pool of people who the IRC Council is comfortable with proposing as operators if any channel needs new operators" [not exact quotation]
[01:54] <PriceChild> somerville32, I've not said anything against that?
[01:54] <somerville32> PriceChild, no, you haven't. I'm asking a question :]
[01:54] <elkbuntu> somerville32, want to reword that? it doesnt make sense
[01:54] <PriceChild> My proposal is more "lets write this down a few details so we can point people to it"
[01:54] <somerville32> elkbuntu, ie. #ubuntu-marketing ops should composed of mostly people involved with that eam
[01:54] <PriceChild> somerville32, yes... and channel contacts choose people connected with their channel.
[01:55] <somerville32> *team
[01:55] <PriceChild> the council does not impose operators on contacts
[01:55] <somerville32> PriceChild, And channel contacts are determined by the IRC council?
[01:55] <PriceChild> somerville32, no not at all...
[01:55] <somerville32> PriceChild, Okay. I'm confused. Could someone point me to where the mandate of the IRC council is located? :)
[01:56] <LjL> The Council definitely does not and does not want to impose operators, but the IRC Team members MAY be asked by any Ubuntu channel's contact to become operators. I think that is the concept.
[01:56] <LjL> somerville32: https://wiki.ubuntu.com/IrcTeam/IrcCouncil
[01:56] <PriceChild> somerville32, ubuntuirccouncil owns the main support channels. Any further teams have their own leadership structure... like #ubuntu-women or #ubuntu-motu
[01:56] <elkbuntu> somerville32, team ops etc are organic as they have always been. The only additional influence of the irc council on this is that we should be listed as operators for emergency situations
[01:57] <LjL> elkbuntu, even that I would propose as optional, though possibly encouraged.
[01:57] <somerville32> So, are there Xubuntu, Kubuntu, Edubuntu, and Gobuntu representatives on the IRC council?
[01:57] <elkbuntu> LjL, yes, encouraged
[01:57] <LjL> I would propose that all channels list Freenode staff as operators, however.
[01:57] <PriceChild> We've already agreed that ubuntu-irc is a list of trusted ops, approved by the council etc. etc.
[01:57] <PriceChild> My issue here is more about how a user _joins_ the team.
[01:58] <AndrewB> Is there a way you could group ubuntu-irc people, having you all on access lists creates long and complicated lists
[01:58] <AndrewB> could you have a specific cloak?
[01:58] <somerville32> What if we changed the launchpad structure up a bit?
[01:58] <LjL> somerville32, some channels are directly administrated by the Ubuntu IRC council, and some are not. Those that are not act in their own interest, although they certainly have to abide by the CoC, and item "The interaction between the IRC Council and channels not directly administrated by it" of this meeting should also address some other points about them.
[01:59] <somerville32> LjL, So, for example, who determines if Xubuntu participates or not?
[01:59] <LjL> AndrewB, I think that could be discussed, but perhaps at a later stage.
[01:59] <PriceChild> This has also been discussed before AndrewB and was dismissed as it was agreed we don't want that sort of hierarchy. ubuntu/members and operators are different, non mutually-exclusive groups.
[01:59] <LjL> somerville32: is the channel contact for the Xubuntu channel UbuntuIRCCouncil?
[02:00] <AndrewB> @ubuntu/member/irc.team.Nick
[02:00] <somerville32> LjL, Is that a username?
[02:00] <AndrewB> If we contacted freenode we could beg for something right?
[02:00] <LjL> somerville32: Yes, it is.
[02:00] <PriceChild> AndrewB, not allowed by freenode
[02:00] <somerville32> LjL, Yes it is.
[02:00] <PriceChild> AndrewB, we can vary the bit between ubuntu and nick but nothing more
[02:01] <AndrewB> I know it is supposed to be project/level/pdpc.level.nick or other but maybe we could beg for a special case?
[02:01] <Tm_T> PriceChild: AndrewB: and how about team members who are not ubuntu members?
[02:01] <AndrewB> Hmm I suppose that is true also
[02:01]  * Seeker` is an ubuntu-irc member, and not an ubuntu member
[02:01] <LjL> AndrewB, I don't think that is particularly needed, anyway... Yes, our operators lists are long, but manageable mostly.
[02:02] <PriceChild> We can add this to our agenda next time...
[02:02]  * AndrewB will do a bit of research on it
[02:02] <elkbuntu> somerville32, the irc council is a desktop-agnostic group. we are responsible for the #*buntu* channels as a whole.
[02:02] <Tm_T> including "official" loco channels I believe
[02:02] <somerville32> elkbuntu, The different flavours are distinct projects.
[02:02] <LjL> Could we turn back to the original topic of the item "Clarification of what the "ubuntu-irc" team actually is and who is eligible to join"?
[02:03] <LjL> Interaction between the IRC Council and channels not directly administrated by it is covered by another item.
[02:03] <somerville32> Can we define what the team is before we decide for can join it?
[02:03] <somerville32> *who
[02:03] <PriceChild> The ubuntu-irc team on launchpad is a group of irc operators, approved by the Ubuntu IRC Council.
[02:04] <LjL> somerville32, I think we are trying to define it, aside from the core definition that PriceChild just gave.
[02:04] <elkbuntu> somerville32, it is seeming like you are taking us along a completely seperate line of discussion to that which we are attempting to discuss
[02:04] <Tm_T> PriceChild: + "known to be trusted" in some way?
[02:04] <somerville32> elkbuntu, Sorry. We all get easily distracted sometimes :]
[02:04] <LjL> Tm_T: If we approve them, then we should trust them ;-)
[02:04] <somerville32> PriceChild, And what does it mean to be a part of that team?
[02:05] <nalioth> somerville32: as mentioned:  a group of irc operators who can be trusted to responsibly step in and help you with your *buntu* channel operations
[02:05] <LjL> PriceChild made a proposal about that question, I believe, right when we began talking about this item, which is the reason the item was brought up in the first place.
[02:05] <Tm_T> LjL: I mean, it should be pointed out in documentation so others really really know it
[02:06] <LjL> PriceChild, perhaps you could summarize your proposal again?
[02:06] <PriceChild> Tm_T, yes.... which is why I added to the agenda and suggested exactly that above
[02:06] <Tm_T> PriceChild: yup
[02:09] <PriceChild> Ubuntu-IRC is a team of operators, approved by the Ubuntu IRC Council. The team exists to give Ubuntu channel contacts a ready pool of enthusiastic, trusted operators for their channel should they need it. Channel contacts should also hopefully be able to trust a user belonging to this group if they request access.
[02:10]  * ajmitch should really leave that team then
[02:10] <Tm_T> ajmitch: you do what you have to do :)
[02:11] <ajmitch> well if it requires enthusiasm... :)
[02:11] <Seeker`> ajmitch: you untrusted? or not enthusiastic?
[02:11] <LjL> PriceChild, as for that definition, +1
[02:11] <LjL> ajmitch: faked enthusiasm is informally allowed.
[02:11] <somerville32> +1
[02:11] <Tm_T> PriceChild: sounds good to me, time shows more :))
[02:11] <ajmitch> Seeker`: as trustworthy as you can throw me, but I predate the council by a long way, in terms of membership
[02:12] <ajmitch> LjL: oh that's alright then
[02:13] <elkbuntu> +1 to the definition
[02:13] <PriceChild> My main want for this meeting, was to write something down of how users get accepted to the team... as I said above: "What has been the case so far afaik, is that a helpful user gets invited to operate in a channel or two (whether by council or other contact), is observed, and hopefully eventually accepted into the ubuntu-irc team where they are in a much better position to request ops in other channels to he
[02:13] <PriceChild> lp out further."
[02:14] <AndrewB> PriceChild: could you remove 'hopefully' it sounds like you *may* not be trusted?
[02:14] <PriceChild> AndrewB, meh details... i put that in there as hoping that the contact would be confident to trust but can see what you mean
[02:14] <somerville32> I don't see the word trust in that
[02:14] <PriceChild> somerville32, the word "hopefully"
[02:15] <AndrewB> Channel contacts should also hopefully be able to trust
[02:15] <LjL> AndrewB, that's just his summary, it's not a final text for anything, keep that in mind
[02:15] <somerville32> Oh, wrong paragraph
[02:16] <AndrewB> sorry LjL and PriceChild I didn't realise. :( heh
[02:16] <LjL> Although the other part, the definition, can be a final text for what I am concerned, as I already expressed my approval for it
[02:16] <elkbuntu> PriceChild, +1 pending edits
[02:16] <somerville32> Looks good to me too
[02:16] <LjL> Same for me, +1, it just needs to be written down, but the way you have expressed it leaves no room to ambiguities really.
[02:17] <PriceChild> So a few things came up when I've discussed this with others before...
[02:17] <PriceChild> So which channels count? Of course there's the ones listed on IrcTeam/Scope, but what about LoCo channels for example?
[02:17] <elkbuntu> nalioth, care to vote?
[02:17] <nalioth> silence is consent
[02:17] <nalioth> +1
[02:17] <somerville32> PriceChild, Why would it extend to loco teams?
[02:17] <nalioth> if i see something, i'll jump right in
[02:17] <AndrewB> The language barrier would cause problems on LoCo channels would it not?
[02:17] <LjL> nalioth, +1 is consent... please, it's two characters, perhaps one hit of Shift :-P
[02:18] <PriceChild> somerville32, because there are ops in ubuntu loco channels etc... and we have had a LOT of loco ops applying
[02:18] <Seeker`> AndrewB: Why would it?
[02:18] <LjL> I believe that the Ubuntu IRC Team, and PriceChild's description of its membership process, should only apply to channels directly administrated by the IRC Council.
[02:18] <somerville32> PriceChild, loco teams should manage their own channels but they should be able to apply join the ubuntu-irc just like anyone else
[02:19] <AndrewB> Seeker`: if you were called to ubuntu-fr  would you have 100 percent clue on what is going on?
[02:19] <Seeker`> AndrewB: You would only respond to calls in languages you understand then
[02:19] <elkbuntu> AndrewB, some incidents you dont need to know the language to know what's going on
[02:19] <LjL> AndrewB, Seeker`, the language barrier is something I will try to address in "The interaction between the IRC Council and channels not directly administrated by it". It should not, indeed, be prejudicial, although it's clear that when a language barrier exists, some things can become more difficult.
[02:20] <elkbuntu> AndrewB, if i joined a channel of any language to see a url a million and one times flooding past my eyes, i think i'd figure it was the problem
[02:20] <PriceChild> My take on it... is half with ljl, half with somerville32. With decisions on accepting an application, we want a majority approval of the IRCC. So if there's a public channel not listed in scope... in which the majority of the IRCC has seen a good sustained contribution by a channel op... then that should be good enough?
[02:21] <somerville32> PriceChild, I agree. The irc team is just a list of trusted operators.
[02:21] <PriceChild> we might all idle in say... #ubuntu-foo on the offchance...
[02:21] <LjL> PriceChild: That should not be excluded, I agree. However, it should be made clear, I think, to channel operators that they should not normally EXPECT to become part of the IRC Team. It could happen, but only after interaction between them and the IRC Council.
[02:21] <AndrewB> Yeah elkbuntu sure, but what about trolling. Remember floods are not allways what you would be called upon [sorry for lagged answer]
[02:22] <PriceChild> LjL, yup. because without that we have no basis on which to make an opinion.
[02:22] <somerville32> LjL, What PriceChild is saying is that loco team ops are not accepted on the basis they are an op in their loco chan - just like #ubuntu-marketing ops aren't automatically accepted. They get accepted based on their interactions with the ubuntu-irc team/council.
[02:22] <LjL> PriceChild: Indeed. It is important that operators realize that fact, though, and that might be worthwhile to communicate to them unambiguously.
[02:22] <elkbuntu> AndrewB, every little bit helps in situations like that. if i can help with the spamming, then i do
[02:23] <LjL> somerville32: That is what I am saying, too. But I am also saying that operators could be made aware of that somewhat more explicitly. Perhaps the "Interaction" meeting item, once again, may enter the equation.
[02:23] <PriceChild> And of course it should go without saying the operator has to agree to CoC, LCoC, user and operator guidelines...
[02:24]  * somerville32 nods.
[02:24] <Seeker`> AndrewB: as i understand it, you wouldn't have to respond to EVERY call for help - you would only respond to trolls, for example, in languages you understand
[02:24] <Pici> lcoc?
[02:24] <PriceChild> Pici, leadership CoC
[02:24] <Pici> PriceChild: okay
[02:24] <somerville32> Seeker`, I don't understand why you are bringing that up.
[02:24] <PriceChild> its referenced off the CoC and our operator guideliens
[02:24] <AndrewB> Seeker`: elkbuntu ok thanks for helping me understand :)
[02:24] <Seeker`> somerville32: I am responding to AndrewB
[02:24] <PriceChild> somerville32, they're having an ongoing conversation
[02:24] <LjL> elkbuntu, AndrewB, as I said, I would still leave the decision on whether to have the Ubuntu IRC Council as an operator on channels to the channel contacts - but ENCOURAGING it should be fine. It is a bit like Freenode does, encouraging channels to +o staff.
[02:24] <Pici> PriceChild: Right, just wasn't familiar with the acronym
[02:25] <elkbuntu> LjL, i said nothing about force
[02:25] <somerville32> LjL, Only the channels under the scope of the IRC council should have the IRC council as a channel contact
[02:25] <LjL> And I am not claiming you did. Just, do we agree that we should actively encourage channels to have the Ubuntu IRC Council as operator?
[02:25] <somerville32> Otherwise, the channel is completely autonomous withstanding CoC
[02:25] <LjL> somerville32: "operator", not "contact".
[02:26] <AndrewB> LjL: I would say yes to that, though I don't think I have any weight heh
[02:26] <elkbuntu> LjL, we should encourage, yes. additionally we should be encouraging the /freenode/staff/* in the access list too
[02:26] <ajmitch> LjL: what would this mean, for loco channels & the like?
[02:26] <somerville32> LjL, I'm agnostic to recommending that because it makes no difference.
[02:26] <LjL> Also, all the #*buntu* channels (almost) are under the scope of the IRC Council, as far as Freenode sees it. It is a matter of network policies.
[02:27] <LjL> elkbuntu, surely we should.
[02:27] <AndrewB> Ouch lag again..
[02:27] <elkbuntu> ajmitch, it means that if there are no active loco ops, then someone else can come to the rescue. it's more important in the big loco channels like -de, -es, -fr
[02:28] <ajmitch> so just the council, not the -irc team?
[02:28] <somerville32> LjL, But is the IRCC allowed to use that power as the namespace contact?
[02:29] <nalioth> ajmitch: anyone on the ubuntu-irc list
[02:29] <elkbuntu> ajmitch, that's up to the loco or team. the irc team is like a 'certified to not boot you all out for laughs' list
[02:29] <PriceChild> somerville32, yes
[02:29] <nalioth> somerville32: yes, we can, if necessary
[02:29] <Pici> Does this mean that IRCC members will need to idle in every loco team channel? Thats a bit extreme.
[02:29] <LjL> I will summarize. The Ubuntu IRC Team is a team of operators trusted by the IRC Council, and a "pool" for other channels in need of new operators. Membership should be based on an IRC Council decision after overseeing the future member's operation of one or more channels. Membership through other means should be explicitly discouraged. Channels not directly under IRC Council control are encouraged to list Freenode staff, and if they so desire the IRC
[02:29] <LjL> Council, as channel operators.
[02:29] <LjL> PriceChild, nalioth, elkbuntu?
[02:29] <PriceChild> This isn't a "this is going to happen...." this is "just incase it does, it coul dbe useful to..."
[02:29] <somerville32> nalioth, PriceChild: That I think there needs to be strict documentation describing when the IRCC can use the "notwithstanding clause" and have it approved by the CC
[02:30] <Seeker`> Pici: No, they could come and find ops in -ops  or something
[02:30] <PriceChild> Pici, no, but we are availiable in -ops and will be able to easily act.
[02:30] <PriceChild> somerville32, read the governence doc.
[02:30] <Pici> PriceChild: Understood.
[02:30] <nalioth> LjL: looks good
[02:30] <elkbuntu> ljl +1
[02:31] <elkbuntu> is this can be finished time now?
[02:31] <elkbuntu> havent we done all the items?
[02:31] <LjL> I don't think there is another meeting upcoming.
[02:31] <ajmitch> elkbuntu: yes, almost beer o'clock
[02:31] <somerville32> When would the IRRC ever need to use the notwithstanding clause without getting CC approval?
[02:31] <LjL> No, but perhaps we should hurry up a bit more.
[02:31] <LjL> Let's move on to the next item please.
[02:32] <LjL> "Clarification on the status of #ubuntu-ops, who may idle, who gets voice"
[02:32] <PriceChild> somerville32, we can request ownership of any channel in the ubuntu or affiliates namespace.
[02:32] <elkbuntu> ajmitch, considering i havent eaten anything except raspberry and pear jelly so far today, im rather looking forward to making some lunch
[02:32] <somerville32> PriceChild, Yes... thats the power you have but when are you allowed to use it?
[02:32] <AndrewB> elkbuntu: can I have some :(
[02:32] <PriceChild> somerville32, when we deem it necessary.
[02:32] <elkbuntu> AndrewB, it might be melted by the time it gets to you
[02:33] <nalioth> somerville32: if you create #ubuntu-child-molesters, the channel _will_ be taken away
[02:33] <PriceChild> somerville32, this is stated in the team governance document, as approved by the CC.
[02:33] <LjL> So, can we now talk about things that were not already decided in previous meetings? "Clarification on the status of #ubuntu-ops, who may idle, who gets voice" is probably the next in list, connected to the previous item.
[02:33] <ajmitch> by the time the CC responds to something, it'd probably be far too late
[02:34] <somerville32> ajmitch, Cases like dealing with rogue channels can easily be documented as an approved use of that power.
[02:34] <elkbuntu> LjL, i would think irc team get voice, trusted observers can idle
[02:34] <LjL> 1) Should we allow or disallow idlers? Should we allow only certain idlers?  2) Do only the people who are member of the IRC Team get voice (in order to be recognized as operators by users), or should that be handled differntly?
[02:35] <PriceChild> somerville32, read the governance document... we've a new topic now.
[02:35] <Hobbsee> somerville32: that sounds like a *very* loaded statement
[02:35] <LjL> elkbuntu, should operators who are not yet IRC Team members not be allowed voice until they are?
[02:35] <LjL> Also, won't disallowing idlers *and* restricting voice to IRC Team members result in "legitimate" handlers being questioned all the time by forgetful operators?
[02:36] <elkbuntu> LjL, on a case-by-case basis
[02:36] <somerville32> Why not just let anyone idle in -ops?
[02:36] <Seeker`> IMO, Ops in "approved" channels (#*buntu*), should be allowed in -ops
[02:36] <PriceChild> My take on this is that I don't mind anyone idling in -ops... as long as they don't have a recent history of trolling or similar on the bantracker.
[02:36] <elkbuntu> LjL, i'd recommend that if you trust them enough to have voice there, that they should be put on the irc team too
[02:36] <PriceChild> We want to be open... we are publically logged.
[02:36] <LjL> somerville32, we are wary of that, because *very* malicious people have idled in #ubuntu-ops in the past.
[02:37] <PriceChild> However I do NOT want any important realtime information going through there being used against us.
[02:37] <somerville32> LjL, How does that affect if they idled in say #ubuntu ?
[02:37] <elkbuntu> somerville32, i covered this before. it's quite a time waster to get attacked in the middle of an issue based on something said in there
[02:37] <somerville32> LjL, err.. what is the difference?
[02:37] <somerville32> elkbuntu, Thats a very valid point.
[02:37] <LjL> somerville32, by idling in #ubuntu-ops, one can find out when operators are away, and what they are doing, and time attacks.
[02:37] <PriceChild> somerville32, because important information can be said in -ops
[02:37] <Seeker`> somerville32: There is information about which ops are active etc. in -ops etc.
[02:37] <somerville32> PriceChild, The channel is logged.
[02:37] <PriceChild> We discuss tactics when dealing with botnets etc. etc.
[02:37] <PriceChild> somerville32, it is not logged in real time.
[02:38] <somerville32> IRC is not mission critical
[02:38] <Seeker`> somerville32: there is a lag with the logs
[02:38] <somerville32> If people spam, they spam
[02:38] <PriceChild> somerville32, the logs are considerably delayed... as I have stated above.
[02:38] <Hobbsee> somerville32: uh, by saying that, you're clearly showing that you *dont* know much about ops
[02:38] <nalioth> somerville32: spam is the least of our worries
[02:38] <elkbuntu> somerville32, you are kidding, right?
[02:38] <Seeker`> somerville32: But if there is a simple step which makes dealing with attacks / improving user experience, shouldn't it be taken?
[02:38] <Seeker`> there should be an "easier" in there
[02:39] <Hobbsee> somerville32: that channel *is* mission critical to us doing ops effectively.
[02:39] <somerville32> I wasn't trying to dispute that.
[02:39] <elkbuntu> somerville32, that channel is next to useless for communicating if there are idiot lurkers in there using it as a chat channel
[02:39] <somerville32> elkbuntu, Agreed.
[02:40] <LjL> I don't believe LoCo operators, in general, should idle in #ubuntu-ops, because I, personally, know too few LoCo operators and so, unfortunately, I cannot really I "trust" many of them. I would like to try to improve this situation, IF we find the time to discuss the "Interaction" item, however.
[02:40] <somerville32> But I don't seee why there needs to be a blanket policy
[02:40] <elkbuntu> somerville32, that's what it becomes when you let anyone idle in there
[02:40] <LjL> We are already very much out of time, on the other hand.
[02:40] <somerville32> Why not just deal with the trouble people like you would in any other channel?
[02:40] <Mithrandir> elkbuntu: either, they are lurkers, or they are using it as a chat channel.  Lurker implies they are not saying anything.
[02:40] <Tm_T> LjL: trusted ops of other channels, so they have to gain our trust ;)
[02:40]  * elkbuntu kciks Mithrandir
[02:40] <nalioth> somerville32: because some malicious people aren't malicious in -ops
[02:40]  * Mithrandir tickles elkbuntu back
[02:40]  * elkbuntu pouts
[02:40]  * AndrewB throws in the freenode/helper gang to, are they welcome?
[02:40] <Seeker`> LjL: How can they interact with you, if they cant be in -ops?
[02:40] <elkbuntu> AndrewB, yes
[02:41] <PriceChild> AndrewB, i'm sure freenode are always welcome.
[02:41] <LjL> Seeker`: I WILL explain that, if we can get to the relevant item.
[02:41] <LjL> But I am starting to suspect we may not.
[02:41] <Seeker`> LjL: Ok, sorry
[02:41]  * Tm_T has waited this moment :))
[02:41] <LjL> Nothing to be sorry about.
[02:41] <PriceChild> I'd like to suggest we are open to all users. However the IRC Council reserves the right to remove any user from the channel. This could be done when a user has a history of trolling, and important information is about to be discussed for example.
[02:41] <Hobbsee> LjL: yes, this does seem like a hijack of the meeting.
[02:41] <PriceChild> Which is pretty much what we do now...
[02:42] <Tm_T> PriceChild: or he is just "looking" IMO
[02:42] <PriceChild> Tm_T, meh... council discression... sometimes it doesn't hurt to have a little chat and explain what goes on.
[02:42] <Tm_T> if someone likes to know what happens there, there's logs, right?
[02:42] <PriceChild> So... +v....
[02:42] <Tm_T> PriceChild: true there
[02:42] <Seeker`> I would like to suggest that there should be a discussion of whether someone should be kicked, rather than 1 op deciding to kick someone
[02:43] <LjL> It is 3:40am in my timezone, and I would like to satisfyingly but speedily conclude this meeting. Can we agree that idlers should be handled on a case-by-case basis by the IRC Council and that, in general, only members of the IRC Team should get voice? I think that, at a later stage, we may modify this policy, and allow more people to have +v status, after some more mechanisms have been set in motion.
[02:43] <nalioth> Seeker`: there usually _is_ a discussion
[02:43] <Tm_T> 0443
[02:43] <elkbuntu> LjL, agreed
[02:43] <Tm_T> LjL: agreed there
[02:43] <Seeker`> nalioth: not always though
[02:43] <PriceChild> Seeker`, not always "publically"
[02:44] <somerville32> +1 LjL
[02:44] <LjL> PriceChild, nalioth?
[02:44] <PriceChild> Seeker`, when dealing with a user in -ops 9 times out of 10 i'll be in pm with someone in pm about it.
[02:44] <Seeker`> as far as I am aware, there was not a discussion about whether I should be kicked from -ops
[02:44] <nalioth> +1
[02:45] <LjL> Seeker`, the IRC Council reserves the right to kick idlers - that was the case before this meeting. I'm sorry, however, about that incident, but there was nothing out of the normal technically.
[02:45] <PriceChild> Shall we discuss "what about the people with +v now who aren't in the team" next time?
[02:45] <LjL> PriceChild, unless we revise the +v status - now or later -, I think they should not have +v right now.
[02:46]  * Hobbsee thinks this comes down to that somerville32 and friends dont trust the current ops, at all
[02:46] <PriceChild> But yes... for now I'd rather we kept new +v's to the ubuntu-irc team for clarity, that's waht it was originally for. If we give it out to lots of people it doesn't really mean anything and we might as well get rid of it.
[02:46] <LjL> I, honestly, would be willing to propose +v status not only for IRC Team members, but in general for people who we know can deal with user complains, even if they are not operators.
[02:46] <somerville32> Hobbsee, Even if that is true, it still is something that needs to be worked through collaboratively and maturely
[02:46] <LjL> However, I think that proposal should be postponed.
[02:46] <Seeker`> LjL: I understand why it was done, and I am happy with the way it was resolved etc., but I was just suggesting that it (s|c)ould be policy to discuss it, unless the user is obviously causing harm
[02:47] <PriceChild> LjL, and users able to deal with complaints should be invited into the team ;)
[02:47] <LjL> PriceChild, I don't agree that's necessarily and always true.
[02:47] <PriceChild> LjL, hehe
[02:47] <Hobbsee> somerville32: by people who actually are in the channels, and know what they're talking about
[02:47] <somerville32> Hobbsee, no.
[02:48] <Hobbsee> so the discussion is not useless
[02:48] <LjL> So, +v only for IRC Team members, pending a possible/likely future revision of this policy. Sounds good?
[02:48] <AndrewB> PriceChild: I would like to see something like that, a clearer path on how to become more involved would be cool ;)
[02:48] <Tm_T> LjL: agreed
[02:48] <PriceChild> Yup... we should organise another meeting pretty soon.
[02:48] <elkbuntu> LjL, yep
[02:48] <somerville32> Hobbsee, You can't have it just a self-selected group having full control over the irc channels.
[02:48] <PriceChild> AndrewB, k cool.
[02:48] <somerville32> Hobbsee, The IRCC needs to be open to hearing opinions from the entire community
[02:48] <LjL> Do we need to talk more about the #ubuntu-ops related issues, or can we move to the next item?
[02:49] <PriceChild> somerville32, you're here... giving your opinion?
[02:49] <somerville32> PriceChild, Yes but Hobbsee doesn't feel I should be allowed
[02:49] <nalioth> somerville32: um, the council was elected.
[02:49] <Tm_T> somerville32: untrue
[02:49] <elkbuntu> somerville32, your tone is not building any trust
[02:49] <Hobbsee> somerville32: not when your'e spreading lies and propoganda, no.
[02:49] <somerville32> ...
[02:49] <PriceChild> moving on.... you can discuss this in private if you wish
[02:49] <somerville32> I can not believe you just said that, Hobbsee.
[02:49] <nalioth> LjL: next item please
[02:50] <LjL> I don't think what is being discussed is relevant to this meeting.
[02:50] <LjL> Yes nalioth
[02:50] <LjL> "The interaction between the IRC Council and channels not directly administrated by it, and improving communication with LoCo channels"
[02:50] <Hobbsee> actually knowing what you're talking about, *before* trying to change it, is usually a good idea.
[02:50] <LjL> I would like to propose means to be in closer contact with the Ubuntu channels that are not directly administrated by the IRC Council, and LoCo channels in particular. Please see the draft at http://www.novarata.net/wiki/index.php?title=Other_Channels - If those ideas are approved, I would like to get in contact with each channel owner about it.
[02:50] <PriceChild> Hobbsee, move to private please :)
[02:50] <nalioth> Hobbsee: somerville32: please continue in #ubuntu-ops if you don't mind  :)
[02:50]  * somerville32 nods.
[02:51] <Tm_T> LjL: from me approved and contacted
[02:51] <Hobbsee> nalioth: fair enough.  but, i dont plan to waste time on it, if it's not going to be listened to and thought about
[02:52] <Seeker`> LjL: That looks like a good plan to me
[02:53] <LjL> I hope it should, in time, both settle problems with LoCo channels and other channels (such as the ones we have discussed earlier), and hopefully also create a new useful environment to interact.
[02:55] <PriceChild> I kinda like the idea of seperating general "about operating/irc" discussion from the bans/appeals/main channel discussions.
[02:55] <LjL> That is also one of the goals.
[02:57] <Tm_T> yup
[02:58] <LjL> I assume you may have issues with some points, as it is a relatively complex proposal, but I suppose that if those issues are minor, they can be discussed in #ubuntu-ops and minor changes made.
[02:59] <LjL> Also, that document does not mention anything about the Ubuntu IRC Team, the #ubuntu-ops channel, UbuntuIRCCouncil as operator, freenode/staff/* as operator
[02:59] <LjL> Since we have discussed all those issues during the meeting, I think the decisions we have reached can be added to that document.
[03:00] <Tm_T> aye from me
[03:00] <LjL> That way, channel contacts and operators will be made aware of them, as well as the other points that are original to that document.
[03:00] <LjL> nalioth, elkbuntu, PriceChild, does the document and the above comments seem reasonable to you?
[03:01] <elkbuntu> yep
[03:01] <PriceChild> Yeah i really like the idea of splitting the two topics into -ops and -irc... and knowing the loco people a little more, making ourselves more obvious if needed etc.
[03:03] <LjL> I think that what is being asked *from* the [support] channels is very trivial and is already being enacted in most, if not all, Ubuntu channels - Respecting the CoC, for instance, should be taken for granted.
[03:04] <nalioth> LjL: looks good for now.
[03:04] <LjL> nalioth?
[03:04] <LjL> Here you are :-)
[03:05] <LjL> Well, if there are no objections, I would like to open the #ubuntu-irc channel, assigning UbuntuIRCCouncil as its contact.
[03:07] <PriceChild> Sounds like a plan... and we will write everything down in the morning...
[03:07] <PriceChild> well... later this morning ;)
[03:09]  * AndrewB yawns
[03:09] <PriceChild> If there's nothing else.... meeting over?! :)
[03:09] <Tm_T> mommy can we go home now?
[03:09] <LjL> Just one thing
[03:10] <LjL> I would like to invite any IRC Team members who are bilingual and who would like to volunteer helping with getting in contact with LoCo channels, whose contacts and operators may not be able to speak English, to ask me to be added to the relevant list
[03:11] <LjL> (Or just add themselves, once the Wiki page is ready)
[03:11] <Tm_T> LjL: as I stated earlier, count me in, en-fi and some swedish if needed
[03:11] <LjL> Noted.
[03:11] <LjL> With this, as far as I'm concerned we can end the meeting.
[03:12] <Vorian> LjL: I can help with about 50 LoCo channels ;-)
[03:13] <LjL> Vorian: US teams don't need translators, we speak English in case you didn't notice ;-P
[03:13] <LjL> at least, I'm so arrogant to assume I do
[03:13] <nalioth> thanks folks, for coming   :)
[03:14] <nalioth> y'all take care and sleep well  :)
[03:14] <elkbuntu> LjL, we speak english. they speak american
[03:14] <LjL> oh right!
[03:14] <Vorian> >.<
[03:14] <LjL> Good night, or morning, or evening, from me too.
[03:14]  * Vorian slithers away
[03:14]  * elkbuntu trots off for a belated brunch
[03:16] <PriceChild> gah sorry I forgot about you Vorian
[03:16] <PriceChild> really sorry.... meeting was kinda hectic
[03:16] <Vorian> PriceChild: no worries
[03:16] <Vorian> LjL's page looks awesome


[00:50] <Takyoji> What is the command for listing all mountable partitions?
[00:50] <Takyoji> I'm trying to manually mount a USB flash drive
[00:51] <Takyoji> ahh, I can also find it from dmesg I guess
[01:37] <Takyoji> casper-rw is the file on a LiveUSB for persistent storage, correct?
[04:54] <Takyoji> March 18th is the day to start taking screenshots in various languages (using Quickshot) for the Ubuntu Manual project; for anyone that's interested.
[04:54] <Takyoji> Also translations
[05:09] <Takyoji> tonyyarusso: A reasonable GUI to bzr on Launchpad is something called "Groundcontrol"
[05:09] <Takyoji> Just answering your question from a couple weeks ago. :P


[21:13] <mhall119> ahoneybun: can you add the Vero Beach release party event to http://loco.ubuntu.com/events/global/3339/
[21:14] <mhall119> you can link to the meetup.com page for RSVPs
[23:23] <ahoneybun> does the LoCo need a location? We have not picked one yet mhall119


[00:18] <kermit> Jason1: back yours up, remove and install the package
[00:19] <kermit> your sshd connection wont die if yuo're remote
[00:24] <Jason1> nothing will change until I do a restart right?
[00:24] <Jason1> What about everyone's keys already in place?
[00:25] <kermit> i think changes take effect immediately
[00:25] <kermit> keys are stored in home dirs
[00:25] <kermit> package management doest mess with home dirs
[00:26] <Jason1> sudo apt-get remove openssh-server ??
[00:27] <kermit> yeah, or aptitude
[00:27] <kermit> no comment on the 'sudo' stuff
[00:29] <Jason1> uninstall and reinstall left the sshd_config file intact
[00:30] <kermit> ohh i think thats an option, to remove config files
[00:30] <kermit> try purge instead of remove
[00:31] <kermit> but that might kill your ssh connectio
[00:31] <kermit> i'll try
[00:32] <kermit> it doestn, so yeah try purge
[00:35] <Jason1> that worked!  Thanks!
[06:37] <Jason1> anyone in here?
[06:41] <tonyyarusso> yup
[07:04] <kermit> Jason1: it seems so
[12:06] <_diablo> lol, seems like he didn't think you two were interesting ;)
[17:18] <_diablo> server going down, be back later


[23:31] <Atamira> such a beautiful day today
[23:53] <chilts> it is nice :)
[23:53] <chilts> finally, a nice day at the weekend


[02:13] <Virusurbano> hey, how are you!
[02:13] <Virusurbano> hello people´.
[02:20] <sgtd> good,you?
[06:04] <ezzieyguywuf> hello jrib :-)
[06:04] <jrib> hi
[06:04] <ezzieyguywuf> so i've downloaded the patch
[06:05] <jrib> doesn't matter where the patch is, just where you are
[06:05] <ezzieyguywuf> ok
[06:05] <jrib> so... where are you?
[06:05] <ezzieyguywuf> well i downloaded the .tar.gz and extracted it
[06:05] <ezzieyguywuf> and i'm in that directory (this is kdebluetooth btw)
[06:05] <jrib> what does 'pwd' say?
[06:06] <ezzieyguywuf> /home/wolfie/Desktop/kdebluetooth-1.0_beta2
[06:06] <jrib> ok
[06:06] <jrib> and 'ls'?
[06:06] <ezzieyguywuf> lots of files
[06:06] <ezzieyguywuf> any in particular we're lookin for?
[06:06] <jrib> and 'ls -d */'?
[06:06] <ezzieyguywuf> acinclude.m4   configure        kdebluetooth               Makefile.in
[06:06] <ezzieyguywuf> aclocal.m4     configure.files  kdebluetooth.kdevelop      po
[06:06] <ezzieyguywuf> admin          configure.in     kdebluetooth.kdevelop.pcs  README
[06:06] <ezzieyguywuf> AUTHORS        configure.in.in  kdebluetooth.kdevses       stamp-h.in
[06:06] <ezzieyguywuf> bemused.patch  COPYING          kdebluetooth.tag           subdirs
[06:06] <ezzieyguywuf> ChangeLog      Doxyfile         Makefile.am                VERSION
[06:06] <ezzieyguywuf> config.h.in    INSTALL          Makefile.am.in
[06:07] <ezzieyguywuf> and admin/  kdebluetooth/  po/
[06:07] <jrib> !paste
[06:07] <jrib> ok
[06:07] <ezzieyguywuf> !paste
[06:07] <ezzieyguywuf> guess ubotu isn't in here
[06:07] <jrib> so... is there a "bemused" directory in kdebluetooth/ ?
[06:08] <ezzieyguywuf> yes
[06:08] <jrib> ubotu is sleeping
[06:08] <jrib> ok
[06:08] <jrib> do you understand what -p does with patch?
[06:08] <ezzieyguywuf> somewhat
[06:08] <ezzieyguywuf> something to do with the location of something
[06:08] <jrib> heh
[06:08] <ezzieyguywuf> :-[
[06:08] <ezzieyguywuf> h
[06:09] <jrib> open up your patch in a text editor for a sec
[06:09] <ezzieyguywuf> ok
[06:09] <jrib> see those first two lines?
[06:09] <ezzieyguywuf> yea
[06:09] <ezzieyguywuf> one looks like a directory and the other one some kind of address
[06:10] <jrib> they tell patch the path to the files it needs to patch
[06:10] <jrib> kdebluetooth/bemused/kbemusedsrv.cpp.old kdebluetooth/bemused/kbemusedsrv.cpp
[06:10] <ezzieyguywuf> ahhh
[06:10] <ezzieyguywuf> i see
[06:10] <ezzieyguywuf> so if i'm in that directory, i don't have to worry about -p right?
[06:10] <jrib> so you are fine without a -p right
[06:10] <ezzieyguywuf> i should be
[06:11] <ezzieyguywuf> ok so recap
[06:11] <jrib> if you were in kdebluetooth, then you would strip the first '/' with -p1
[06:11] <ezzieyguywuf> but if i'm in bemused
[06:11] <ezzieyguywuf> i'm fine
[06:11] <ezzieyguywuf> correct?
[06:11] <jrib> no
[06:11] <jrib> well
[06:11] <ezzieyguywuf> ?
[06:12] <jrib> where you are now, you would use -p0 to tell it not to strip anything
[06:12] <ezzieyguywuf> ok
[06:12] <ezzieyguywuf> and by strip you mean take stuff off the end of where it thinks the files are
[06:12] <ezzieyguywuf> right?
[06:12] <jrib> if you pass no -p then it strips everything and you need to be in the same dir
[06:13] <ezzieyguywuf> ok
[06:13] <jrib> kdebluetooth/bemused/kbemusedsrv.cpp with -p1 will be bemused/kbemusedsrv.cpp
[06:13] <ezzieyguywuf> well, if i ls right now i see both files
[06:13] <jrib> kdebluetooth/bemused/kbemusedsrv.cpp with -p2 will be kbemusedsrv.cpp
[06:13] <jrib> what does 'pwd' return?
[06:14] <ezzieyguywuf> /home/wolfie/Desktop/kdebluetooth-1.0_beta2/kdebluetooth/bemused
[06:14] <jrib> ok
[06:15] <ezzieyguywuf> ok so i should run patch with no -p correct?
[06:15] <ezzieyguywuf> or with -p0
[06:15] <ezzieyguywuf> or are both the same
[06:15] <jrib> that is ok here because both files are kdebluetooth/bemused/kbemusedsrv.cpp and kdebluetooth/bemused/amarokcontroller.cpp
[06:15] <jrib> no -p
[06:15] <ezzieyguywuf> ok i get it
[06:15] <ezzieyguywuf> and this is going to compile the whole program using that patch
[06:15] <ezzieyguywuf> correct?
[06:15] <jrib> -p0 would say no
[06:15] <jrib> I mean: no
[06:16] <jrib> patch just patches (modifies) files
[06:16] <ezzieyguywuf> oh
[06:16] <ezzieyguywuf> so i have to have it installed first
[06:16] <jrib> you should have patch
[06:16] <ezzieyguywuf> cuz i'm running patch right now and the terminal is just kind of, froze
[06:16] <jrib> hit ctrl-c
[06:16] <ezzieyguywuf> no output
[06:17] <ezzieyguywuf> that kills the program right?
[06:17] <jrib> the syntax is:  patch > /path/to/file.patch
[06:17] <jrib> ugh
[06:17] <jrib> the syntax is:  patch < /path/to/file.patch
[06:18] <ezzieyguywuf> oh!
[06:18] <ezzieyguywuf> it works
[06:18] <ezzieyguywuf> i did not think the < was needed for some reason
[06:18] <ezzieyguywuf> wow thanks
[06:19] <ezzieyguywuf> so now that the files are patched
[06:19] <ezzieyguywuf> i have to compile the whole thing right, with those patched files?
[06:19] <jrib> yes
[06:20] <ezzieyguywuf> ok and i think that link you gave me will help with that
[06:20] <ezzieyguywuf> dpkg-buildpackage
[06:20] <jrib> yes
[06:20] <ezzieyguywuf> ok
[06:20] <ezzieyguywuf> i'll go try to figure out how that works
[06:20] <ezzieyguywuf> i'll ask if i have any questions
[06:20] <ezzieyguywuf> :-)
[06:23] <ezzieyguywuf> ok so where exactly does dpkg need to be run from?
[06:24] <ezzieyguywuf> it says "from the directory that was created for the package after downloading"
[06:24] <ezzieyguywuf> i didn't use apt-get to download the package, i just got it from the website, so its on my desktop
[06:24] <ezzieyguywuf> and i'm in the directory, but dpkg returns dpkg-parsechangelog: error: cannot open debian/changelog to find format: No such file or directory
[06:24] <jrib> then follow the first set of instructions ubotu sent
[06:25] <jrib> then you don't get a package though
[06:26] <ezzieyguywuf> ?
[06:26] <ezzieyguywuf> i'm sory i don't follow
[06:26] <jrib> deb
[06:26] <jrib> you don't get a deb if you don't use apt to grab a source package
[06:26] <ezzieyguywuf> oh i see
[06:26] <ezzieyguywuf> ok, let me go try this over with apt-get then
[06:29] <ezzieyguywuf> jrib:kdebluetooth-1.0_beta2
[06:29] <ezzieyguywuf> er h/o
[06:30] <ezzieyguywuf>  Unable to find a source package for kdebluetooth-1.0_beta2
[06:30] <jrib> that's not the name of the package
[06:30] <jrib> no need to ping me in two channels :)
[06:30] <ezzieyguywuf> oh sorry
[06:30] <ezzieyguywuf> i don't know if you keep checking here
[06:31] <ezzieyguywuf> how do i find the name of the package? cuz i need that particular beta version
[06:32] <ezzieyguywuf> you know what, i was looking at the wrong link, i never checked the prvt message from ubotu
[06:32] <ezzieyguywuf> let me go read that real quick :-)
[06:39] <jrib> night
[06:42] <n2diy> jrib: 73
[06:42] <jrib> n2diy: ?
[06:42] <jrib> 3874
[06:42] <jrib> i win
[06:43] <n2diy> jrib: google 73
[06:43] <jrib> The Romans capture Masada ?
[06:44] <jrib> The atomic number of tantalium ?
[06:45] <n2diy> jrib: Wait please?
[06:45] <jrib> k
[06:46] <n2diy> jrib: Try this: http://www.ac6v.com/73.htm#73
[06:49] <jrib> cool, never knew that
[06:54] <n2diy> jrib: 10-4 :)
[06:55] <jrib> 73
[06:58] <n2diy> jrib: 73 OM :)
[07:05] <ezzieyguywuf> jrib still here?
[08:30] <pentux> hello Fritha - welcome to ubuntu-classroom
[14:02] <aleph1> hi
[14:03] <jrib> aleph1: is this after an upgrade or just random apt breakage?
[14:03] <aleph1> powercut in the middle of "aptitude update"
[14:04] <jrib> that wouldn't do it
[14:04] <jrib> "upgrade" maybe?
[14:04] <aleph1> sorry. yeah
[14:04] <aleph1> but I think I have found a solution.
[14:04] <jrib> k
[14:04] <aleph1> I replaced /etc/init.d/mysql with "exit 0"
[14:05] <aleph1> but thanks! :)
[14:05] <jrib> aleph1: glad you got it
[14:57] <dholbach> MOTU Q&A session in two minutes
[14:59] <Amaranth> I forgot the name of the other channel :/
[14:59] <dholbach> hello everybody :)
[14:59] <dholbach> welcome to the MOTU Q&A Session!
[14:59] <dholbach> who do we have here - can we go through a round of introductions? :)
[14:59] <Amaranth> Oh, this isn't Open Week yet :)
[15:00] <dholbach> I'm Daniel Holbach, MOTU for quite a while now and trying to make becoming a MOTU as easy and enjoyable as possible. :)
[15:01] <dholbach> who else do we have here? :)
[15:01] <persia> I'm Emmet Hikory, MOTU, and active with QA and library porting.
[15:01] <fernando> I'm Fernando Ribeiro, trying to be a MOTU.
[15:02] <dholbach> hey rulus, ntaylor0909, nalioth_, welcome to the session - we're just going through a round of introductions
[15:02] <sommer> me... Adam Sommer I'm relatively new to the community and looking for ways to contribute.  Was at another QA meeting, but was called away before the end.
[15:02] <zul_> im chuck short, member of the motu team amongst other things
[15:02]  * dholbach high-fives sommer
[15:02] <geser> I'm Michael Bienia, MOTU
[15:03] <dholbach> who of you is interested in becoming a MOTU and has prepared some questions for us? :)
[15:03] <rulus> dholbach: I'm just listening :)
[15:03] <gaspa> andrea gasparini, not motu.
[15:03] <gaspa> :-P
[15:03] <sommer> I'm interested, but didn't come prepared with anything specific.
[15:03] <dholbach> sommer, rulus, gaspa: great to have you around
[15:04] <dholbach> anything you'd like to know about MOTU? contributing or ubuntu development?
[15:04] <gaspa> there' s already a roadmap, or a list of things that i can do to help ubuntu development?
[15:05] <dholbach> gaspa: sure
[15:05] <dholbach> on http://wiki.ubuntu.com/MOTU/TODO we list quite a lot of different things you can start looking into
[15:05] <dholbach> the 'bitesize' bugs for example are suited for new contributors for example
[15:05] <dholbach> 'packaging' bugs deal with packaging related problems, that *might* be easy to fix
[15:05] <gaspa> dholbach: ok, i saw only the hardy roadmap, but it's quite vague.
[15:06] <dholbach> gaspa: we'll be fixing a lot of bugs, so I think that's a good way to get involved in the MOTU team
[15:06] <gaspa> yep, just starting in it ;)
[15:07] <dholbach> http://wiki.ubuntu.com/MOTU/Recipes will help you to play with the tools we use most
[15:07] <norsetto> perhaps gaspa is referring to this: https://wiki.ubuntu.com/UbuntuDevelopment ?
[15:07] <huats> gaspa: and sometimes if you are doing stuffs on a bug with a MOTU called norsetto as a mentor on this bug, be prepared to do a lot of things, even for a bitesize bug... But you'll learn a lot...
[15:08] <norsetto> huats: I never asked you to do a triple somersault .....
[15:08] <dholbach> hey nealmcb
[15:08] <dholbach> norsetto: not yet :)
[15:08] <persia> gaspa: You might also take a look at https://wiki.ubuntu.com/MOTU/Contributing, which has some suggestions on using the tools, and some of the basic processes for getting things uploaded.
[15:08] <huats> dholbach: :-D
[15:08] <gaspa> norsetto: I was referring to https://wiki.ubuntu.com/HardyReleaseSchedule?highlight=%28hardy%29
[15:09] <dholbach> gaspa: right, that page only explains the various phases of the release cycle we'll go through
[15:09] <nealmcb> dholbach: howdy.  I was late to the other discussion, just caught up on the log, and figured I'd lurk some more here
[15:09] <dholbach> and it's not even a final document yet :)
[15:09] <norsetto> gaspa: yes, but I think if you want to know more about ubuntu development, you really should look at the wiki link I posted
[15:09] <gaspa> dholbach: in fact i wasn't satisfied. ;)
[15:09] <dholbach> nealmcb: excellent :)
[15:09] <persia> gaspa: That's more a schedule to keep track of how release management affects our work.  The goals are more to implement as many features as we want prior to Feature Freeze, and fix as many bugs as possible.
[15:10] <norsetto> persia: fix bugs? which bugs?
[15:10] <dholbach> any other questions around packaging, MOTU, Ubuntu Development, processes?
[15:10]  * norsetto forgot that the Bug Master is in the room
[15:10] <persia> norsetto: All of them would be great, but most new people would do best with those with the bitesize tag.
[15:11] <huats> norsetto: you mean the packaging king right ?
[15:11] <dholbach> he must mean seb128 and pedro_ :)
[15:11] <huats> dholbach: I have one question for you
[15:11] <huats> :-)
[15:11] <dholbach> huats: fire away
[15:11] <norsetto> dholbach: how can a contributor submit a patch?
[15:11] <dholbach> norsetto: good question :)
[15:12] <dholbach> it's all explained at http://wiki.ubuntu.com/SponsorshipProcess
[15:12]  * norsetto writes that down
[15:12] <huats> right now, do what distribution we put in the changelog ? gutsy or gutsy-proposed ?
[15:12] <dholbach> the gist of it is: if you're fixing a bug, attach the patch that you've produced and subscribe the reviewer team to it
[15:12] <dholbach> for main/restricted that's ubuntu-main-sponsors
[15:12] <norsetto> huats: hardy
[15:12] <dholbach> for universe/multiverse that's ubuntu-multiverse-sponsors
[15:13] <Amaranth> Whoa even I didn't know about requestsponsor
[15:13] <persia> s/ubuntu-multiverse-sponsors/ubuntu-universe-sponsors/
[15:13] <dholbach> If you've never produced a patch before: https://wiki.ubuntu.com/MOTU/Recipes/Debdiff might help you with that
[15:14] <dholbach> persia: yes, sorry - was a bit distracted, as I just got a call :)
[15:14] <dholbach> hiya blueyed
[15:15] <blueyed> Hi dholbach :)
[15:16] <dholbach> huats: if you want to fix a bug in gutsy (it's already release, so we can't upload to 'gutsy' itself any more), you'll need to follow http://wiki.ubuntu.com/StableReleaseUpdates
[15:16] <dholbach> (which has both instructions for main and universe)
[15:16] <gaspa> ok, if i decide to write a patch for a bug in https://wiki.ubuntu.com/MOTU/TODO, what should i do to prevent  someone else from making the same work?
[15:17] <dholbach> I just noticed that seb128 didn't do the most uploads after all: http://ubuntu.joejaxx.org/ :-)
[15:17] <norsetto> gaspa: you should assign the bug to yourself
[15:17] <gaspa> norsetto: i can't
[15:17] <gaspa> i launchpad i can't modify nothing of the bug.
[15:17] <norsetto> gaspa: you can't!? Ask for membership in the bugsquad then
[15:17] <dholbach> gaspa: you need to login to launchpad and click for example on the status of the bug
[15:17] <dholbach> norsetto: that's not required
[15:18] <norsetto> dholbach: ah, yes, perhaps he is not logged
[15:18] <gaspa> ... i wasn't able to do it... i'll retry...
[15:18] <gaspa> no ,i'm logged...
[15:18] <dholbach> gaspa: click for example on the status of the line in the middle of page, which has the status/sourcepackage etc information
[15:19] <gaspa> i'll retry later, maybe i lost something.
[15:19] <dholbach> gaspa: and follow up with information on the bug as you have new findings to report, that's also important to not do the same work twice
[15:19] <dholbach> gaspa: alright, let me know if things still go wrong, or ask on #launchpad
[15:19] <gaspa> yep
[15:19] <gaspa> ah, but...
[15:19] <nxvl> is there going to be Q&A meeting?
[15:20] <norsetto> nxvl: right now
[15:20] <dholbach> welcome nxvl :)
[15:20] <persia> nxvl: #ubuntu-classroom
[15:20] <nxvl> here or in #ubuntu-meetings?
[15:20] <huats> I am experiencing some timeout with LP today too... so may be it is related to your pb gaspa
[15:20] <persia> nxvl: here
[15:20] <gaspa> if I assign the bug to me, when does it becomes fixed? when i attach a debdiff?
[15:20] <nxvl> :D
[15:20] <persia> gaspa: When it gets uploaded.  The changelog in your debdiff will close the bug.
[15:21] <persia> gaspa: You'll unassign yourself when you add the debdiff, and use http://wiki.ubuntu.com/SponsorshipProcess to get a sponsored upload.
[15:21] <seb128> dholbach: thanks to the rocking contributors we had in the desktop team this cycle ;-)
[15:21] <norsetto> gaspa: when you subscribe u-u-s, if your patch is accepted, the sponsor will mark the bug as fix-committed, and then, as persia said
[15:22] <dholbach> seb128: care to advertise the DesktopTeam and what contributors can do in it? :)
[15:22] <seb128> the desktop team is a wonderful place to contribute to the Ubuntu desktop ;-)
[15:23] <coNP[uni]> Desktop Team definitely rocks :)
[15:23] <seb128> we have a nice IRC channel (#ubuntu-desktop), a mailing list, a wiki (https://wiki.ubuntu.com/DesktopTeam)
[15:23] <seb128> the wiki has a summary of the team and pointers, we also have a TODO on https://wiki.ubuntu.com/DesktopTeam/TODO
[15:24] <seb128> we welcome questions, etc on #ubuntu-desktop and usually contributors find sponsor easily for their patches or updates so feel free to join ;-)
[15:24] <seb128> dholbach: good enough ? ;-)
[15:24] <norsetto> seb128: what was that thing about champagne free for any patch uploaded?
[15:24] <dholbach> seb128: sounds good - especially the kick-ass DesktopTeam/TODO page :)
[15:24] <huats> seb128: If I wasn't already convinced I would have been....
[15:25] <seb128> coNP[uni] is one of the rocking contributors which joined the team this cycle ;-)
[15:25] <seb128> some things we are looking at for hardy BTW
[15:25] <coNP[uni]> It is not impossible to become a MOTU
[15:25] <coNP[uni]> :)
[15:26] <seb128> - packaging GNOME 2.21.n to 2.22.1, listing annoy glitches laying around for too long that we should fix for the coming lts, make the wiki documentation nicer, and maybe switch to packaging in bzr if we can make the workflow easy enough ;-)
[15:26] <dholbach> that sounds like a lot of action in the hardy cycle :-)
[15:26] <seb128> yes
[15:27] <seb128> would also be nice to have some webpage summary for things like version of the package in ubuntu, debian, upstream
[15:27] <seb128> patches browsable easily for upstream also
[15:27] <dholbach> also experimental versions
[15:28] <seb128> well, I've abused enough this classroom with desktop advertising, I'm waiting for you on #ubuntu-desktop now ;-)
[15:28] <dholbach> but yeah - sounds like a nice small project for somebody :)
[15:28] <dholbach> ok. any other questions?
[15:29] <dholbach> maybe a problem somebody has, we look at together?
[15:30]  * norsetto welcomes giftnudel to the MOTU Q&A session
[15:31] <sommer>  /me admits to still reading the packaging guide
[15:31] <dholbach> sommer:  that's no problem
[15:31] <dholbach> norsetto, coNP[uni], huats: do we have an easy bug we can tackle in the remainder of the session?
[15:31] <persia> sommer: That's great.  Reading is probably the best way to get questions :)
[15:31]  * norsetto checks
[15:31] <coNP[uni]> bug 1
[15:31] <coNP[uni]> Oh, no :(
[15:32] <sommer> is it better to be proficient with packaging from scratch section before moving on?
[15:33] <sommer> or jump to the more automated tools?
[15:33] <norsetto> bug 154399 seems a nice bitesized one
[15:34] <norsetto> ubotu seems to be sleeping: https://bugs.edge.launchpad.net/ubuntu/+source/util-linux/+bug/154399
[15:34] <dholbach> sommer: I think it's good to work on easy bugs to get a feeling of what you're dealing with
[15:34] <persia> sommer: I'd recommend reading the entire guide to build familiarity, and then working with a bunch of different packages while chasing bugs, to see different implementations.  That will likely give a better understanding than trying to understand completely from the guide.
[15:34] <sommer> persia, dholbach: ah, sounds good
[15:34] <dholbach> norsetto: ok, so how do we attempt to fix it?
[15:35] <persia> sommer: That's the big advantage of open-source :)  it's easy to build on others work.
[15:35] <norsetto> dholbach: well, I would first check if nfs-utils is in the repo
[15:35] <norsetto> dholbach: for instance apt-cache search nfs-utils
[15:36] <norsetto> make sure you have an updated cache first
[15:36] <norsetto> anyone has done that?
[15:36] <dholbach> I don't have it
[15:37] <dholbach> I have a source package called nfs-utils though - I used    apt-cache showsrc nfs-utils    for that
[15:37] <norsetto> anyone know what that is?
[15:38] <norsetto> do you know what is a source package?
[15:38] <norsetto> dholbach: will you or shall I?
[15:38] <dholbach> norsetto: go ahead :)
[15:39]  * coNP[uni] votes for norsetto :)
[15:39] <sommer> isn't a source package a package that will build multiple binaries?
[15:39] <norsetto> ok, I try .....
[15:39] <coNP[uni]> sommer: you can have one or more binaries built from a source package
[15:39] <norsetto> sommer: yes, a source package its a pacjage that contains, as the name says, the sources, and the instructions for the build system on how to make binaries out of it
[15:40] <norsetto> you download source packages with the apt-get command too; for instance apt-get source nfs-utils
[15:40] <geser> if you have a deb-src line in /etc/apt/sources.list
[15:41] <norsetto> so, you see, in this case there is a source package for nfs-utils, but there is no binary package
[15:41] <norsetto> geser: yes ;-)
[15:41] <dholbach> and the binary package is the .deb package that gets actually installed
[15:41] <norsetto> if you do an apt-cache search nfs-utils you will see that nfs-utils is actually provided by another package, its a virtual package
[15:42] <coNP[uni]> Actually you can also download a source package for a binary package, with apt-get source <binarypackagename>
[15:42] <coNP[uni]> So you don't have to know the source package name.
[15:43] <norsetto> now you just have to check if the man page object of the bug is really provided by the nfs-common package
[15:43] <norsetto> one way to do it (there are many) is to download it, and check its content with a dpkg -c command
[15:44] <giftnudel> isn't it sufficient to look at the file list for that?
[15:45] <norsetto> giftnudel: you mean the one at http://packages.ubuntu.com/? As I said, there are many ways to do it
[15:45] <giftnudel> well, you explained it already :)
[15:45] <sommer> so to address the bug, would you change the mount man page to say install nfs-common instead of nfs-util?
[15:45] <norsetto> sommer: if the man page is indeed in nfs-common, yes
[15:46] <sommer> norsetto: but it may not be?
[15:46] <sommer> ah you check the nfs-util package, correct?
[15:46] <norsetto> sommer: I would also check the options section, to see that it indeed contains the mount options for nfs and nfs4
[15:47] <giftnudel> ls
[15:47] <giftnudel> ups :)
[15:47] <geser> sommer: this is also a check if the information from the bug is correct
[15:48] <sommer> yep, mount has options for nfs and nfs4
[15:49] <norsetto> sommer: we should check that in the nfs man page too
[15:50] <sommer> norsetto: okay, I'm not finding anything in the mount man page about nfs-utils though.
[15:51] <norsetto> sommer: what distribution are you using?
[15:51] <sommer> norsetto: Gutsy
[15:51] <giftnudel> well I can see it there
[15:51]  * geser too
[15:51] <giftnudel> right at the bottom
[15:51] <sommer> I did man mount... is that right
[15:51] <giftnudel> yes
[15:52] <giftnudel> then go to the end and you should see it
[15:52] <sommer> woops I'm blind
[15:52] <sommer> I see it now
[15:53] <norsetto> sommer: I think it is because using space you end up with the header just at the end, so you may miss it
[15:54] <sommer> norsetto: I used /nfs to do a search and when it highlighted the nfs part I skipped over the -utils at the end... heh
[15:55] <norsetto> has any of you tried to check the nfs-common package, and its nfs page?
[15:55] <giftnudel> at least the dpkg seems to contain it and debian/nfs-common.manpages wants to install it :)
[15:55] <sommer> norsetto: trying to install it now.
[15:56] <norsetto> also checking it with: http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=nfs.5.gz&searchmode=searchfilesanddirs&case=insensitive&version=gutsy&arch=i386
[15:57] <norsetto> ok, so we checked the correctness of the bug report, the solution given was correct, do we all agree?
[15:57] <sommer> I concur
[15:58] <dholbach> what do we do now? :)
[15:58] <norsetto> how do we actually patch this out, anyone?
[15:58] <giftnudel> well, in the mount source package change the string?
[15:58] <sommer> move the man page back to nfs-util, or change the man page of mount?
[15:59] <giftnudel> the first idea is also nice :)
[15:59] <norsetto> sommer: well, I think changing the man page of mount is more appropriate, but, is there anything else we should check first?
[15:59] <sommer> why it was changed?
[16:00] <norsetto> sommer: exactly .....
[16:00] <sommer> probably in nfs-util changelog?
[16:00] <norsetto> sommer: could be, we could also ask upstream, perhaps is something specific to ubuntu
[16:01] <giftnudel> maybe there's a patch in debian already ...
[16:01] <norsetto> giftnudel: good point
[16:01] <norsetto> norsetto: anyhow, for the sake of the exercise, lets suppose we need to patch this
[16:02] <norsetto> how would we go about it?
[16:03] <sommer> apt-get source mount
[16:03] <norsetto> in which source package is the mount man page?
[16:03] <sommer> then find the man page file and edit it
[16:04] <sommer> util-linux?
[16:04] <giftnudel> sommer: yes, it's in tehre
[16:04] <norsetto> sommer: thats what the reported said, seems like he knows what is doing, but lets check it
[16:04] <proppy> hi, Q&A still going on ?
[16:05] <dholbach> proppy: right now norsetto helps us to fix https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/154399
[16:06] <norsetto> ok, so everybody agrees is in there?
[16:06] <proppy> ok
[16:06] <giftnudel> finding the offending file is not that difficult, but then
[16:07] <norsetto> giftnudel: yes?
[16:07] <giftnudel> editing is not appropriate, so we need a patch, right?
[16:07] <proppy> using cdbs-edit-patch ?
[16:08] <norsetto> proppy: is the package using it already?
[16:08] <giftnudel> how do you see that?
[16:08] <sommer> giftnudel: why isn't editing the file appropriate?
[16:08] <proppy> by checking dependencies in control and include in rules
[16:09] <norsetto> there is also a nice util you can use to determine what patch system a package is using, its called what-patch, and its in ubuntu-dev-tools
[16:09] <huats> sommer: since you won't easily remember every modification you've done... so there are tools to help you.... norsetto just mentions...
[16:09] <persia> sommer: giftnudel: It depends on the package.  In general, patches are preferable to direct edits, but some packages don't use patches, and we avoid adding patch systems.  The tool norsetto advises may be the easiest way to decide.
[16:10] <huats> sommer: you will edit the file, but with the tool
[16:10] <sommer> ah... thanks I'm with ya
[16:10] <nealmcb> pardon a query out of the blue: what is u-u-s?
[16:10] <proppy> sommer: if the file you need to edit is not in debian/ then I've been told you need to patch
[16:10] <norsetto> nealmcb: ubuntu-universe-sponsors
[16:11] <nealmcb> :-)
[16:11]  * proppy apt-get sourcing the package
[16:11] <dholbach> nealmcb: http://wiki.ubuntu.com/SponsorshipProcess
[16:11] <giftnudel> it doesn't seem that util-linux has patches in it already, at least I see none and the control file doesn't have dependencies on a patch system
[16:11] <giftnudel> proppy: that's what I remembered, too
[16:12] <sommer> so it's cool to directly edit this package?
[16:12] <norsetto> giftnudel: I think you are correct, so in this case we have two options, either we do an inline patch or we include ourselves a patch system
[16:13] <norsetto> personally, I will never go for inline, even in a simple case like this, but others may have differnt opinions
[16:13] <nxvl> what are we working at? i losted lot of the conversations :S
[16:13] <persia> norsetto: Please reconsider.  For many packages, we try to sync back to Debian, and some Debian maintainers are strongly opposed to patch systems, as it breaks their workflow.
[16:14] <proppy> the package seems to do some man tweaking already
[16:14] <proppy> 	perl -pi.bak -e 's/agetty/getty/g' debian/util-linux/usr/share/man/man8/getty.8 \
[16:14] <norsetto> persia: yes, in thats case I simply revert it back when we merge
[16:14] <proppy> debian/rules:71
[16:15] <norsetto> but persia is right, we should try to stick with what the debian maintainer is doing, so, in this case we might have to do, as proppy suggested, a little hacking
[16:15] <sommer> sweet... lets hack!
[16:15] <giftnudel> its only one line, so it's probably not bad
[16:16] <proppy> "as proppy suggested, a little hacking" I like the sound of that :)
[16:16] <nxvl> is Q&A still going on?
[16:17] <dholbach> nxvl: if you read the backlog, you will find that it's still going on :)
[16:17] <proppy> norsetto: by inline you mean using sed/python/perl/awk/cat ?
[16:17] <nxvl> dholbach: :D
[16:17] <norsetto> proppy: or simply manually changing the source
[16:18] <norsetto> the change will be in .diff.gz
[16:18] <proppy> norsetto: how can you change something which is not in debian ?
[16:18] <dholbach> LjL: ?
[16:18] <LjL> dholbach: bot is down
[16:18] <nxvl> dholbach: so what are we working at?
[16:18] <nxvl> dholbach: MOTU/TODO?
[16:18] <proppy> so you will end with a .diff.gz with 'outside of debian/ changes ?
[16:18] <dholbach> nxvl: check out the back log - it's still the same bug: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/154399
[16:18] <proppy> norsetto: I thought it was not accepted
[16:19] <norsetto> proppy: its debatable, personally, I don't like it, its makes it difficult to trace your changes
[16:19] <giftnudel> proppy: probably a case of "Never ever do that, but know, it's just easier"
[16:19] <giftnudel> (now, not know)
[16:20] <proppy> giftnudel: norsetto: understood thanks for clearing it up
[16:20] <sommer> norsetto: why is it harder to trace changes?  Wouldn't it show up in the debdiff?  also documented in changelog?
[16:21] <norsetto> sommer: yes, but it is showing up in the .diff.gz too, and that change will be incremental
[16:21] <dholbach> sommer: imagine you have 10 different patches all applied directly to the source
[16:21] <norsetto> sommer: so, suppose you do 10 changes, how do you associate the changelog to the change?
[16:21] <dholbach> sommer: they affect 30 different files, now you want to remove one patch of them, because you understood that it's obsolete
[16:21] <proppy> norsetto: I guess we need also to patch SEE ALSO ?
[16:21] <dholbach> it's easier, if you can just remove one patch file in debian/patches :)
[16:22] <sommer> ah... I'm with you
[16:22] <persia> sommer: Also consider that upstream may want your patches, and may only apply a subset.  It's a lot easier to deapply them separately when you manage them separately.
[16:22] <norsetto> and you know immediately which one
[16:22] <dholbach> great
[16:22] <sommer> thanks, that makes sense now.
[16:22] <dholbach> excellent
[16:23] <norsetto> dholbach: are we running short on time?
[16:23] <dholbach> if you guys want to continue, go ahead, that's fine - anybody who doesn't have time anymore, can go :)
[16:24] <giftnudel> so for just a simple fix like that, there's nothing that speaks against it, but for bigger patches, individual patches are  better
[16:24] <norsetto> so, what do we do once you have your patch? In this case corrected the line in the man page?
[16:24] <norsetto> somebody mentioned a changelog?
[16:24] <sommer> dch -i?
[16:24] <norsetto> sommer: for instance
[16:25] <norsetto> what is it going to be the new version number?
[16:25] <persia> giftnudel: rather, it's better to follow the package you're working with.  Even a one-line change deserves a dedicated patch if the package has an patch system in use.
[16:25] <giftnudel> right, I forgot that
[16:26] <sommer> norsetto: good question... I'm still fuzzy on version numbering.
[16:26] <proppy> norsetto: perl -pi.bak -e 's/nfs \(5\)/nfs-common \(5\)/g' correct ?
[16:27] <norsetto> sommer: its not difficult, check what is in the changelog already
[16:27] <norsetto> proppy: I like it when you talk to me like that ;-)
[16:27] <proppy> norsetto: ubuntu2 ?
[16:28] <norsetto> proppy: yes, in this case the old one was 2.13-8ubuntu1, so, since this is an ubuntu revision, we will use 2.13-8ubuntu2
[16:28] <norsetto> what if the old one was 2.13-8 ?
[16:28] <giftnudel> proppy: well, should nfs-utils not be changed to nfs-common?
[16:29] <norsetto> brb
[16:29] <proppy> giftnudel: you're right, my patch is bad :)
[16:29] <proppy> giftnudel: I missread the bug report
[16:30] <sommer> in 2.13-8. -8 is the debian package number correct?
[16:30] <proppy> giftnudel: the package is to be changed, not the manpage name
[16:30] <dholbach> sommer: yes
[16:30] <dholbach> sommer: if we do an ubuntu change, we simply add ubuntu1 and then increment it
[16:30] <sommer> dholbach: gotcha
[16:30] <dholbach> sommer: if we were the first to package 2.14 (which is not in debian yet, we'd have 2.14-0ubuntu1
[16:30] <norsetto> sorry about that, important phone call
[16:31] <dholbach> norsetto: don't worry
[16:31] <sommer> okay... so the 8 isn't the 8th ubuntu version?
[16:31] <norsetto> ok, anything else we should do?
[16:31] <norsetto> sommer, no its the debian revision
[16:31] <persia> sommer: That's the Debian revision.  For any -XubuntuY, X is the Debian revision, and Y is the Ubuntu revision.
[16:31] <dholbach> coNP[uni], persia, huats, geser are here too and can help out :)
[16:32]  * dholbach is about to call it a day
[16:32] <norsetto> a little thingie that we should not forget .....
[16:32] <dholbach> thanks everybody for showing up, thanks norsetto for running the biggest part of the session :)
[16:32] <norsetto> since we made an ubuntu modification, we should also change the maintainer
[16:32] <proppy> giftnudel: perl -pi.bak -e 's/nfs-utils package must be installed/nfs-common package must be installed/g' better ?
[16:32] <sommer> cool... I think I'm good on revision numbers now too, thanks fellas
[16:33] <sommer> dholbach: thank you
[16:33] <dholbach> rock on :)
[16:33] <giftnudel> I wanted to help so often, but everytime I wanted to fix such an easy thing, there was so much I needed to think of and then I resigned again ...
[16:33]  * dholbach hugs y'all - see you around, guys
[16:34] <norsetto> giftnudel: please come to #ubuntu-motu and ask for help, we are there also for this
[16:34] <giftnudel> yeah, I sometimes forget that ...
[16:34] <sommer> norsetto: what would we change the maintainer to?
[16:35] <proppy> it is not enough to know *what* line to add, we should also figure *where* :)
[16:35] <sommer> I see it's already Ubuntu-Core
[16:35] <norsetto> sommer: yes, in this case you are correct
[16:35] <giftnudel> proppy: somewhere in the mount pos-inst part of control?
[16:35] <giftnudel> or that vincinity
[16:36] <giftnudel> eh, rules
[16:36] <giftnudel> or the mount.postint
[16:36] <giftnudel> so many places where this might work ...
[16:37] <proppy> where is the mount.8 installed ?
[16:37] <proppy> oh I just grepped it in mount.files
[16:37] <norsetto> ok guys, I have to go too, it was nice talking to you, see you again in #ubuntu-motu
[16:38] <sommer> norsetto: thanks I appreciate your help
[16:38] <giftnudel> yes, hopefully
[16:40] <proppy> giftnudel: why not in rules install: target ?
[16:40] <giftnudel> well, I don't know
[16:41] <proppy> that's where there is already some patching going on
[16:41] <proppy> me neither
[16:41] <giftnudel> yes, for this reason it's probably better there
[16:43] <sommer> I gotta run too... thanks all
[16:43] <proppy> but the install: target is large which line :)
[16:44] <proppy> maybe near 	dh_installdocs -i -s
[16:44] <proppy> just after the endif
[16:46] <proppy> oops maybe Q&A is ended ? anybody stillup ?
[16:48] <coNP[uni]> proppy: sure
[16:48] <coNP[uni]> But you can also ask on -motu as always.
[16:49] <proppy> o k
[16:49] <proppy> giftnudel: still up to work on it ?
[17:44] <LjL> Ubotwo: PART


[00:28] <lazyPower> is there a way to auto-arrange icons in the juju-gui?
[00:29] <lazyPower> googling yields the answer 'no'
[03:14] <rick_h_> lazyPower: it's supposed to do some work to keep overlapping down but it needs some love
[16:11] <rick_h_> I'll take that response even if it's missing a word in the middle https://twitter.com/esacteksab/status/515895888791621632


[15:22] <yano> https://limberbutt.com/
[15:22] <jenni> [ Limberbutt 2016 – Meow Is The Time ] - https://limberbutt.com


[05:10] <stochastic> Hey everyone, who in here is currently running a firewire audio device?
[05:27] <ailo> stochastic, I have one
[05:27] <ailo> focusrite sapphire pro 40
[05:28] <ailo> Works fantastic on Oneiric with a -lowlatency kernel
[05:28] <ailo> I had to recompile my own. Going to see if I can put it up on my PPA later
[05:33] <stochastic> ailo, it's been a while since I've had a working firewire-enabled computer and I'm trying to get my presonus firepod working on my new laptop
[05:33] <stochastic> what steps are needed to get things rolling out the gate?
[05:33] <stochastic> 11.10 install - fresh
[05:33] <ailo> stochastic, Since 11.04 firewire cards work out of the box
[05:34] <ailo> You only need to be a member of audio group in order to run jack
[05:34] <stochastic> okay, well I get nothing but crashes over here
[05:34] <ailo> One thing I had to do to get mine working was having to have the card on while I stuck in the cord
[05:34] <stochastic> is jack set to 'realtime'?
[05:35] <ailo> Just use standard jack settings
[05:35] <stochastic> I always boot up with the device on and plugged in
[05:35] <ailo> Now, mine is behaving differently for some reason, so I can get it working by first injecting the cord, and then turning the device on
[05:36] <stochastic> hey what do you know, unchecking 'realtime' in jack set it up fine, now to run some audio tests
[05:37] <ailo> Ok, then you were not a member of audio group?
[05:39] <stochastic> yes, I was a member of the audio group
[05:39] <stochastic> I did remember that step in earlier config tests
[05:41] <ailo> stochastic, Did you logout login? Cause, that would be the only thing I can think of why realtime would not work.
[05:42] <ailo> stochastic, Here's why your device works out of the box "/lib/udev/rules.d/60-ffado.rules"
[05:42] <ailo> So, you don't need to set any rights for the firewire device itself
[05:42] <ailo> However, in order to get jack to run it in realtime, you need to be in audio group
[05:42] <ailo> If you want to double check, just run jack as root
[05:44] <ailo> stochastic, So, in short, to get a firewire device working, generally the only thing you need to consider is being a member of audio group
[05:48] <stochastic> ailo, well I have the card hooked up, trying to record into an ardour session but the track won't record (nor will the ardour transport start - or the jack transport for that matter) any suggestions?   I also see no levels in the ardour track inputs.
[05:55] <ailo> stochastic, I would double check with the onboard card, and if all else fails, try the firewire device with OSX or Windows
[05:55] <ailo> I mean, double check that everything works fine with alsa, and the onboard card
[05:56] <ailo> Don't have any specific knowledge about your device
[05:57] <ailo> I would also make sure it works in realtime, which is kind of essential I believe in order to get any kind of good performance
[05:58] <ailo> stochastic, Good luck. Gotta go now :)
[06:56] <intenzo> hi!
[06:56] <intenzo> does anyone here know it its possible to start a capture at a specific smpte time in dvgrab?
[06:57] <holstein> anything is possible, but i would probably try and 'do it in post'
[06:58] <intenzo> do it in post?
[06:58] <holstein> yeah
[06:58] <holstein> grab, edit afterward
[06:58] <intenzo> ah
[06:58] <intenzo> well i got 4000 dv tapes to copy so i realy need to automate
[06:59] <intenzo> ;)
[06:59] <holstein> whats the issue?
[06:59] <holstein> you'll need to set the grab times per tape then
[07:00] <intenzo> theres 2min of colorbars and black picture in the beginning of every tape
[07:00] <holstein> i still think any editing would be easier than anything during capture
[07:01] <intenzo> for some reason i can set the end time but not the start time
[07:01] <intenzo> just thought that was wierd and was afriad i had missed something in dvgrab
[07:01] <holstein> not sure
[07:01] <holstein> im not sure who's maintaining that package
[07:02] <intenzo> do you know any alternatives to dvgrab?
[07:02] <holstein> not sure who would know either
[07:02] <holstein> not a lot of video folks here unfortunately
[07:02] <holstein> and what i do , i just edit
[07:07] <intenzo> think I'll have a look on the dvgrab code to see if I can do something clever
[07:08] <intenzo> thanks!
[07:08] <holstein> intenzo: good luck
[07:09] <holstein> intenzo: feel free to comment on the mailing list
[07:09] <holstein> i see some video chatter there sometimes
[07:09] <holstein> VERY rare in this channel though...
[07:10] <intenzo> well it was a long shot, but thought that some here would have some knowlige about it
[07:11] <intenzo> i'll get back if i find a good solution
[14:31] <intenzo> holstein: I solved it
[14:31] <intenzo> a fried made a custom build of dvgrab ;)
[14:31] <intenzo> it adds a startcapture option
[14:32] <intenzo> https://launchpad.net/~rawler/+archive/ppa
[14:46] <holstein> intenzo: w0w
[14:46] <holstein> sometimes i tell people the software is open, and they technically can make it do anything
[14:47] <holstein> rarely does someone actually do it though :)
[14:47] <intenzo> hes f_ing great
[14:49] <intenzo> also, it was a rather easy patch so all other functionality is there and should work as espected