[01:18] <tjiggi_fo> anyone here?
[01:19] <Silverlion> tjiggi_fo: affirmative
[01:19] <tjiggi_fo> read this: http://pastebin.com/kcJMVaE3 and tell tsimpson to read it too
[01:34] <phillw> Silverlion: the one from tjiggi_fo ?
[01:34] <Silverlion> phillw: affirmative
[01:40] <phillw> Silverlion: I got bored... If someone would tell me what the infraction is? As it was reported from -ot and being asked to be on there, what is the issue?
[01:41] <Silverlion> phillw: i have not a single clue ... just got the link from tjiggi_fo
[01:41] <Silverlion> with the request to pass it to tsimpsion
[01:42] <phillw> let them sort it out. I do not touch -ot areas unless there is a clear breach of freenode regs.
[01:42] <phillw> I treat -ot as an ## area
[04:52] <bazhang> gassypoots clearly has no interest in being helped
[12:51] <theadmin> Get rid of crizzy please, saying Windows is better than Linux in an Ubuntu channel is unacceptable
[13:02] <oCean> ehrm...
[13:42] <topyli> phillw: problem is, -ot is not in fact ## area. it is an ubuntu channel where our guidelines stand
[13:43] <topyli> please don't make your own interpretations of what is and what should be. these things are very clear unless we ourselves start messing them up
[13:45] <phillw> topyli: I do know that all channels fall under freenode rules, but what is acceptable on an offtopic channel <> support channel. When the rules are clearly written, we can follow them & make sure others also do.
[13:46] <topyli> ubuntu channels have their own rules in addition to freenode's
[13:47] <topyli> which are clearly written down
[13:47] <phillw> So, can you answer me what is the point of -ot if it is not a placce to stretch your legs away from support channels?
[13:47] <topyli> that is exactly the point
[13:48] <topyli> what's the question? :)
[13:51] <phillw> topyli: I treat -ot as ## in terms of policing. Can you point me to the rules that let me know the policing differences between a support channel an -ot and where they differ from ##? I'm all for learning as a trainee :)
[13:52] <Myrtti> first of all we'd need to know what you think defines "##"
[13:52] <topyli> the "policing" is exactly the same, only the channels have different topics. #ubuntu is for support for example, #ubuntu-offtopic is for relaxing. your ## interpretation just does not hold
[13:52] <phillw> Myrtti: a room that follows freenode rules, no other additional rules
[13:53] <Myrtti> er right
[13:53] <topyli> -ot certainly does not fall under that definition
[13:53] <phillw> I'm glad that our -ot does not fall under that remit, then :)
[13:54] <Myrtti> so you treat it as something that fall under only freenode rules?
[13:54] <Myrtti> falls, even
[13:54] <phillw> Myrtti: yeah, we do.. that is the raison d'etre for it.
[13:55] <topyli> who is "we"?
[13:55] <topyli> because you're wrong in this matter
[13:55] <phillw> topyli: the people authorised to action breakage of the freenode rules. Those rules are nice and straight forward
[13:56] <Myrtti> that would explain a few things I've not understood about the channel, and is also somewhat worrysome.
[13:56] <phillw> topyli: I'm all ears, do please explain.
[13:56] <topyli> nobody is authorized to break freenode rules
[13:56] <phillw> correct
[13:57] <Myrtti> and you don't expect people in #lubuntu-offtopic to honor Ubuntu Code of Conduct, or IRC guidelines?
[13:58] <phillw> IIRC applies to #lubuntu and is enforced. -ot follows freenode rules. As to why CoC / IIRC wish to enforce additional rules on the -ot area is, IMHO well outside of your remit.
[13:58] <tsimpson> following the Code of Conduct is a requirement in all Ubuntu related channels (as well as any other form of communication in the Ubuntu community), the IRC Guidelines are really just an IRC-specific extension to that code
[13:59] <phillw> tsimpson: which part of CoC is not covered in freenode rules? I'm not being antagonistic, I really do want to learn the difference.
[13:59] <topyli> #lubuntu-offtopic is in the ubuntu namespace, and is expected to follow the CoC and the IRC guidelines. i don't think this is negotiable. if you want a channel with easier expectations, feel free to create a channel outside our namespace
[14:00] <tsimpson> the Guidelines are (iirc) a requirement for the core channels, other channels can either choose to use it or not
[14:00] <tsimpson> the CoC is not optional in any part of the community
[14:00] <phillw> topyli: that's odd, Ubuntu Beginners Team did, and it got closed down.
[14:01] <topyli> #lubuntu-offtopic qualifies as a core channel
[14:01] <phillw> topyli: qualifies by whom? When was the vote held?
[14:02] <phillw> #lubuntu is a core channel & allowed official bots, -ot was never mentioned.
[14:02] <topyli> no votes. it is documented here: https://wiki.ubuntu.com/IRC/IrcTeam/Scope
[14:02] <tsimpson> phillw: https://wiki.ubuntu.com/IRC/IrcTeam/Scope contains a definition of what qualifies as core
[14:03] <topyli> #l-ot is "Main off-topic/discussion channel for Ubuntu, or for an officially supported or officially recognised Ubuntu derivative"
[14:03] <tsimpson> in short, main support and offtopic channels for Ubuntu and official (as defined by Canonical) derivatives
[14:03] <phillw> I note the word "qualify", it does state "has to be"
[14:03] <topyli> it is a core channel, that's not for discussion
[14:03] <phillw> *does not*
[14:04] <phillw> thank you all for clearing that up. I will pen an email to the lubuntu members telling them that -ot is no longer -ot
[14:05] <Myrtti> *sigh*
[14:05] <phillw> ditto
[14:06] <tsimpson> phillw: if it was a place where the CoC could be violated at whim, then please do pen an announcement stating that it's no longer the case
[14:06] <phillw> tsimpson: there is never a case where CoC breach would be tolerated
[14:07] <tsimpson> so it's just the IRC Guidelines that you object to? if so, which part(s) in particular don't fit with #lubuntu-offtopic?
[14:07] <tsimpson> by "object to", I mean "object to being applied to #lubuntu-offtopic"
[14:09] <phillw> But, I seek clarification on where IIRC rules are different to freenode rules for an -ot?
[14:10] <tsimpson> the rules are freenode rules + Code of Conduct + IRC Guidelines
[14:10] <topyli> it should be obvious that ubuntu offopic channels are different from #defocus, for example
[14:10] <phillw> I was the guy who asked for -ot precisely to have an area away from the support channel.
[14:10] <tsimpson> there's nothing stopping it from being that
[14:11] <phillw> then, to go full circle.. why does someone find it worrysome about #lubuntu-ot ?
[14:12] <Myrtti> I doubt anyone is coming to the channel slapping the rules on the table and killing the discussion right now because the rules are different, unless you do it
[14:12] <topyli> i'm pulling up the pub analogy again. there are some where anything goes, and there are some where a certain standard of behavior is expected unless you want to be thrown out. ubuntu channels fall in the latter category
[14:12] <Myrtti> but the fact that you didn't know or realise that the Code of Conduct of IRC guidelines apply to #l-ot is worrysome
[14:12] <Myrtti> atleast to me
[14:13] <topyli> phillw: i don't even know what #lubuntu-offtopic is like. i took issue with your comment about the guidelines and how they supposedly don't apply to the channel
[14:13] <phillw> topyli: as a holder of a pub licence I know what you mean. I explain to my staff that there is a line in the sand that may not be crossed.
[14:13] <topyli> right
[14:14] <Myrtti> on top of that there is the nationwide laws about serving alcohol
[14:14] <Myrtti> and countywide licence restrictions.
[14:15] <topyli> these might be analogue to the freenode rules, in this discussion. the ubuntu guidelines are the pub-specific standards
[14:15] <phillw> topyli: in an -ot I, personally would only intervene if it was a breach of freenode. They have a good set of rules, I also use both the standard CoC and the advanced one for people placed in a position of trust.
[14:16] <Myrtti> there is a saying in Finnish and I think it fits here. Lillukanvarsia.
[14:16] <phillw> topyli: you will be familiar with the standard version of http://forum.phillw.net/viewtopic.php?f=12&t=29
[14:16] <topyli> phillw: i see. but your job is to uphold the CoC and the IRC guidelines in your channels
[14:16] <topyli> so i suggest you rethink this
[14:17] <tsimpson> there already is a leadership code of conduct
[14:17] <tsimpson> http://www.ubuntu.com/project/about-ubuntu/leadership-conduct
[14:18] <phillw> tsimpson: oddly enough, that is the one! As released under share and share alike by Ubuntu
[14:18] <Myrtti> honestly, if things keep working without a hitch and people behave as expected, it doesn't matter which document sanctions flipping the bird on a channel or mooning the channel goers
[14:18] <topyli> heh
[14:18] <Myrtti> So now that we've established the fact that code of conduct, freenode rules and irc guidelines apply to #l-ot, I don't see where the problem is
[14:18] <Myrtti> as long as you are aware that they do
[14:19] <Myrtti> and since you've already been acting like they do, even if you've called the tomato toumatou instead of tohmato, then we're sorted
[14:20] <Myrtti> the name of the document is irrelevant, it's what is acted on that means something
[14:20] <topyli> yeah
[14:21] <phillw> Myrtti: we all came up though the ranks, as I actioned OP privs to people they had to to convince me that they had not only understood the 'basic' CoC, but also the higher one.
[14:22] <topyli> good policy
[14:22] <phillw> The glee is that the task of so deciding on a "fit and proper person" no longer weighs upon my shoulders .... IRCC now does that :D
[14:23] <topyli> the ircc no longer has the ability to be aware of all good op candidates on all ubuntu channels, so it is up to you to identify them in the #lubuntu space and encourage them to apply
[14:24] <Myrtti> write testimonials on their wikipage and/or IRCC email address and the bright light shall shine
[14:26] <phillw> topyli: the reason I parted company from UBT was 'council'. I'm really pleased to see UBT have scrapped it, had they had people like Alan on theirs things would not have gotten silly. I spend a fair bit of time and energy encouraging people to take up the challenge of being a moderator on IRC / Forum etc.
[14:28] <topyli> if you think a council is doing a bad job, you change the people. you don't have to throw away the entire institution - it was created for a purpose
[14:28] <phillw> Myrtti: watch benonsoftware, he is already a full ubuntu member at the tender age of 14. He, and the likes of AlexAv are our future. It really is a privalidge to assist them.
[14:30] <Myrtti> I've seen Linux geeks who have been brilliant at age 14. Then I've also seen people who haven't been.
[14:31] <topyli> there are brilliant 14 year olds and there are 41 yeah olds you don't even want to look at
[14:31] <Myrtti> the prime example is now studying in nearby technical university and she AFAIK compiled the kernel for the first time when she was 14 or so. She must be 19 or so now.
[14:31] <topyli> breaking news, people are different! but i do believe everyone is good at something
[14:33] <topyli> how old was marcelo when he started maintaining the linux kernel? 16 maybe?
[14:33] <topyli> 18
[14:33] <phillw> We have seen the spectacular rise and fall of MichealH ... That really hurt me, as I reckoned he would 'make the grade'... but not every apprentice gets past the finishing line. To hark back to the pubs... I am a trainer for people in the cellar side of it. some pass, some fail.
[14:34] <topyli> maybe this should continue in -ops-team if we're talking about people with names
[14:34] <phillw> topyli: so true, everyone has a talent. The key to happiness is finding it & encouraging them to follow it.
[14:34] <topyli> indeed
[16:43] <tjiggi_fo> [01:42] <phillw> I treat -ot as an ## area
[16:43] <tjiggi_fo> Thank you for voicing that sentiment phillw - you speak for a not insignificant proportion of the Ubuntu community.
[16:45]  * oCean blinks
[16:52]  * phillw hates it when some one pings (mentions your name) and then is not there when you have finished what you were doing :/
[16:55] <mneptok> phillw: late to the "party" here ... but "Don't use public away messages" is in the U IRC Guidelines, and certainly Freenode policy does not care.
[16:55] <AlanBell> tjiggi_fo does not appear to be much of a conversationalist
[16:55] <AlanBell> I suspect tjiggi_fo is reading the logs so maybe that person might like to stick around a bit next time they pop in
[16:58] <mneptok> AlanBell: please stop talking to the ceiling and take your meds.
[16:58] <oCean> hehe
[16:59]  * AlanBell takes caffeine as the doctor advises
[17:13] <phillw> mneptok: [[but "Don't use public away messages" is in the U IRC Guidelines, and certainly Freenode policy does not care.]] can I ask when and how I did that? I use pidgin for IRC. if it re-logs me as idle I attempt to castrate it. This is the 1st time I've ever been alerted to it.....
[17:33] <mneptok> phillw: no no. i'm just pointing out a place where the IRC Guidelines and Freenode policy diverge.
[17:34] <mneptok> phillw: -ot channels are held to that standard, which is in no way part of standard network policy.
[17:42] <phillw> mneptok: you state standard, would you care to share with me which one the -ot follows? Guidelines and policy are very different animals in terms of enforcement.
[17:44]  * popey considers cooking AlanBell and eating him.
[17:45] <pangolin> lol
[17:45]  * AlanBell suggests a nice Chianti. And whats for pud?
[17:45]  * pangolin hands popey a cookie instead
[17:46] <jussi> popey's hunting humans... whoooaaaoo...
[17:46] <AlanBell> there might be something somewhere in the guidelines that is too #ubuntu specific, and isn't that relevant to other channels. That is why bug 788503 exists and we should fix that
[17:48] <AlanBell> but in general that looks like stuff that every channel could be happy with
[17:52] <phillw> mneptok: AlanBell I once again apologise, but I'm still having a problem with what is and is not allowed on #l-ot, do we follow the standard "behave" as per freenode, or does IRCC stick extra rules on?
[17:53] <AlanBell> that isn't really the point of the IRCC
[17:53] <pangolin> phillw: the rules for all ubuntu channels are follow the CoC which happen to coincide with the freenode rules.
[17:53] <AlanBell> it is not about rules and regulations and enforcement and stuff
[17:54] <AlanBell> we just administer the channels that the Ubuntu community use with the objective of making them a welcoming and productive place for everyone
[17:54] <phillw> So, if the channel ops on #l-ot are happy with the chat, we need not intevene?
[17:54] <AlanBell> the Code of Conduct is a general set of principles that the Ubuntu community endorses
[17:54] <AlanBell> first line of which is . . .
[17:55] <AlanBell> This Code of Conduct covers our behaviour as members of the Ubuntu Community, in any forum, mailing list, wiki, web site, IRC channel, install-fest, public meeting or private correspondence.
[17:56] <AlanBell> there is incidentally nothing in the Code of Conduct that says swearing is bad per se. however we like to keep the IRC channels suitable for participants of all ages so we keep the language fairly clean most of the time
[17:56] <AlanBell> and that principle is just as true in offtopic channels as it is in support channels
[17:57] <AlanBell> though swearing in support channels comes across as unprofessional as well as unsuitable
[17:57] <phillw> AlanBell: #lubuntu be came "owened" by IRCC, this is an old discussion. Our Ops were vetted by ourselves to the higher standard of CoC
[17:57] <ikonia> is this really happening ?
[17:58] <ikonia> phillw: how hard is this to grasp. The official ubuntu channels follow the official ubuntu guidelines
[17:58] <ikonia> concept even
[17:58] <ikonia> #lubuntu #lubuntu-offtopic #lubuntu-$anything are official channels so they follow the official rules.
[17:58] <ikonia> how is this not a simple concerpt to grasp
[17:59] <phillw> ikonia: how hard is to grasp the difference between a support chanell and an off topic one?
[17:59] <ikonia> phillw: the topic of the channel have nothing to do with it
[17:59] <ikonia> phillw: the guide lines of the channel are the same #
[18:00] <phillw> ikonia: thank you for finally clarifying that! I was under the impression that -ot channels are lightly policed.
[18:00] <AlanBell> I remain confused as to why this is an issue
[18:00] <ikonia> AlanBell: as do I
[18:00] <ikonia> it's just going on the same thing over and over
[18:00] <ikonia> phillw: good, glad it's clear, all ubuntu official channels follow the same guidelines
[18:01] <Myrtti> its tomato tomato discussion
[18:01]  * pangolin grabs the mayo and bread
[18:01] <AlanBell> it really isn't much to do with "official channels" either
[18:01] <pangolin> popey: marmite with your tomato?
[18:02] <AlanBell> I would expect members of the Ubuntu community to be just as nice and friendly in other channels they are in
[18:02] <phillw> ikonia: the issue was when did #l-ot get elected? We accept #lubuntu as IIRC, but it was a surprise to learn -ot is also under IIRC rules, instead of lubuntu OP staff rules.
[18:03] <AlanBell> whut?
[18:03] <AlanBell> see this is what I am confused about
[18:03] <ikonia> phillw: elected ? we accept ? what are you talking about
[18:03] <AlanBell> it has nothing to do with officialness
[18:03] <ikonia> phillw: it's in the ubuntu namespace
[18:04] <AlanBell> part of the Ubuntu Community is more the point
[18:05] <phillw> AlanBell: many, many months ago I was asked to enable IIRC as OP's on #lubuntu. This was during a serious problem with the TL of Speech Control. That request was granted by me as a matter of courtesy.
[18:06] <Myrtti> loco channels aren't governed by ircc, but they still should use the guidelines
[18:06] <phillw> ikonia: no, it is not ... lubuntu was granted # status by freenode.
[18:06] <ikonia> what ???
[18:06] <ikonia> freenode
[18:06] <ikonia> phillw: what are you talking about
[18:06] <Myrtti>  they can't be enforced by ircc, but it's the general idea
[18:06] <phillw> we were not adopted... please do read our history.
[18:07] <ikonia> ??
[18:09] <phillw> we ran ourselves, and still do. We do not have a council, nor ranks. That is prohibited as per a meeting that was held to discuss it.
[18:09] <pangolin> This is how I see the issue. when #lubuntu first started up it was a separate entity and governed by what I can believe was phillw (with absolute power by him) You (the lubuntu project) asked to become official and the project worked very hard and succeeded. Now that Lubuntu is officially a part of Ubuntu which makes the IRC channels subject to the Ubuntu IRC rules ( the IRCC) phillw YOU no longer have the power and I think it is time for you
[18:09] <pangolin>  to understand that. You no longer make the rules, you no longer decide who can be an op, you are now subject to the decisions of the IRCC.
[18:09] <ikonia> sorry, but this is just nonsense
[18:10] <Tm_T> what is nonsense?
[18:10] <ikonia> phillw: if you don't want to follow the ubuntu IRC guidelines, I suggest you quit the project, sorry, but you're just being a problem too much now with this sort of nonsense
[18:10]  * Tm_T is still reading the logs so doesn't know the full story yet
[18:10] <ikonia> good luck with it
[18:10] <Tm_T> ikonia: that cleared it, I think (:
[18:11] <phillw> pangolin: you have got it soooo wrong, I'll go drop my +F right now to prove just how wrong you are.
[18:11] <pangolin> and that right there sir is proof why you should be removed from the access list
[18:11] <pangolin> and removed from the ops team.
[18:11] <pangolin> I'm done.
[18:12] <ikonia> the channels are part of the ubuntu project, they follow the ubuntu guidelines/rules whatever word ticks your box, if you're not confortable with that, thats something you'll have to square with yourself.
[18:12]  * AlanBell wonders off to have dinner
[18:12] <ikonia> yeah, I'm out, this is just babble
[18:12]  * phillw wanders off
[18:13] <phillw> please remove me from IRC OPS, If we cannot discuss things, then there is no point.
[18:14] <pangolin> there is no discussing when someone refuses to accept the inevitable truth.
[18:14] <Myrtti> ho hum...
[20:11] <pangolin> @mark #ubuntu * [pfifo]<EMAIL_ADDRESS>telling user to pirate Windows.
[20:11] <pangolin> @mark #ubuntu  [pfifo]<EMAIL_ADDRESS>telling user to pirate Windows.
[20:13] <pangolin> he is also a time waster.
[20:42] <dax> ikonia: he's still doing it, btw
[20:43] <ikonia> he's muted so I wasn't paying attention
[20:43] <dax> *nod*
[20:43] <ikonia> gone
[20:43] <ikonia> can't be bothered wasting time
[20:43] <ikonia> thanks for the heads up
[22:10] <Silverlion> good evening


[16:11] <DJones> Is there the start of a bot/spam attack happening in #ubuntu? Lots of joins with nick "e" and a random 4/5 digit number, all from the same ip address <IP_ADDRESS>, floodbots seem to be catching them & changing channel mode with more joining once the mode is changed back to normal
[16:11] <DJones> ok, mass k-line just happened for them
[16:19] <Tm_T> DJones: uhhuh
[16:40]  * jussi hugs DJones
[16:58] <DJones> :)
[22:13] <andresmujica> hi, good evening.
[22:13] <erUSUL> !hi
[22:13] <andresmujica> i wonder if some irc operator can give us a hand at #ubuntu-charlas and #ubuntu-charlas-chat
[22:13] <andresmujica> we're currently under siege by some nuts
[22:14] <erUSUL> andresmujica: who has access on that channels ? irc council ?
[22:15] <andresmujica> hmm not pretty sure.. i suppose they have access.
[22:15] <erUSUL> andresmujica: you have access all ubuntu memebers have
[22:15] <erUSUL> andresmujica: so op yourself ...
[22:15] <andresmujica> yeap. i'm as op.    can you help me with some commands?
[22:16] <andresmujica> in fact i muted the channel and we're giving voice to the right ones
[22:16] <erUSUL> isn't m4v around ?
[22:16] <andresmujica> however some of these guys are changing their nicknames using offensive words ...
[22:16] <erUSUL> andresmujica: ban ?
[22:17] <andresmujica> i'm absolutely ignorant with this.. but how can i ban an ip network... ??
[22:17] <erUSUL> andresmujica: /mode +b *!*@hotname
[22:17] <andresmujica> thks
[22:18] <erUSUL> andresmujica: /mode +b<EMAIL_ADDRESS>[22:18] <erUSUL> for example
[22:18] <erUSUL> andresmujica: for the webchat users a ban of this type
[22:18] <andresmujica> thks erUSUL :)
[22:19] <erUSUL> andresmujica: for webchat users ---> /mode +b *!~55542326@*
[22:19] <erUSUL> andresmujica: just use the correct thing instead of that numbers ...
[22:22] <erUSUL> andresmujica: me das voice en -charla ;P ?
[22:23] <erUSUL> andresmujica: en #ubuntu-charlas-chat please :)
[22:23] <andresmujica> erUSUL: yap.  yo've got voice now :)
[22:28] <erUSUL> andresmujica: you have to kick them too
[22:28] <erUSUL> andresmujica: or /remove
[22:39] <erUSUL> andresmujica: /mode +b<EMAIL_ADDRESS>en #ubuntu-charlas-chat
[22:41] <andresmujica> erUSUL: how can i make a regexp??  /mode +b *!*UBUNTU@*  is valid for UBUNTUXXXX ?
[22:41] <erUSUL> andresmujica: *UBUNTU*!*@* o bien *!A@*
[22:42] <erUSUL> andresmujica: UBUNTU*!*@* o bien *!A@* o bien<EMAIL_ADDRESS>( para UBUNTUCACA<EMAIL_ADDRESS>)
[22:42] <erUSUL> andresmujica: la que pusiste no es valida
[22:43] <andresmujica> erUSUL:  y para bloquear la red 201.255.*.* ?
[22:43] <erUSUL> andresmujica<EMAIL_ADDRESS>[22:46] <andresmujica> thks erUSUL :)


[06:47] <stub> bug 2162
[06:47] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[06:48] <stub> Bug 2162
[06:48] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[06:48] <lifeless> bug stub
[06:49] <stub> lifeless, jamesh: Would making launchpad emit an Expires: <current timestamp> header be a bad thing?
[06:49] <lifeless> stub: depends on what you want to achieve
[06:59] <stub> bum
[07:03] <stub> (12:49:11) stub: lifeless, jamesh: Would making launchpad emit an Expires: <current timestamp> header be a bad thing?
[07:08] <lifeless> 16:49 < lifeless> stub: depends on what you want to achieve
[07:08] <lifeless> 16:51 -!- stub<EMAIL_ADDRESS>has quit [Remote closed the connection]
[07:08] <lifeless> I wondered what I had said
[07:09] <stub> Our pages are dynamically generated, so browsers should always fetch fresh copies. Although I'd rather they didn't if you hit the 'back' button
[07:09] <lifeless> then expires is wrong
[07:10] <lifeless> in fact, in general, you can't have it both ways
[07:10] <lifeless> either browers are allowed to cache, or they aren't.
[07:10] <lifeless> OR
[07:10] <lifeless> you teach them how to know when things have changed.
[07:10] <lifeless> (vary:)
[07:11] <lifeless> read (now) section 14.44 of rfc 2616
[07:14] <stub> I'm not sure how that would help us in the Launchpad situation.
[07:15] <lifeless> whats the precise situation that we are trying to address ?
[07:15] <stub> Launchpad content should never be cached, because it is dynamic and could change at any time, and if that breaks the back button tough
[07:15] <stub> lifeless: People visiting a page for the second time and the information not being up to date
[07:16] <stub> lifeless: Such as people logging in, getting redirected to the front page, and the front page telling them they are not logged in.
[07:16] <stub> But the problem exists everywhere - it is just less noticable.
[07:17] <lifeless> then vary: *, as the spac says
[07:18] <lifeless> A Vary field value of "*" implies that
[07:18] <lifeless>    a cache cannot determine from the request headers of a subsequent
[07:18] <lifeless>    request whether this response is the appropriate representation.
[07:18] <lifeless> (browsers must meet the non shared cache requirements)
[07:18] <lifeless> but the front page is *different* because the cookie: header changes when people log in
[07:18] <lifeless> so there is actually a rule we can use there to signal that it should be refreshed.
[07:19] <lifeless> we should try very hard to have cachable pages.
[07:19] <lifeless> not 'cachable by squid', cachable by the client for reasonable times.
[07:19] <lifeless> only some of our pages are infinitely variable over short time frames.
[07:20] <stub> Almost all of them are - it is just the probablility
[07:20] <lifeless> right, and thats what caching is about
[07:20] <stub> and how much we care about the changes
[07:21] <lifeless> until we satisfy If-Matches, we'll perform like a wounded dog if no caching is possible by the client
[07:21] <lifeless> consider that this includes hackergotchi and emblems
[07:21] <lifeless> and the If* matches and revalidation are still waay suboptimal
[07:21] <stub> Nah - librarian stuff is never expires. Images and resources like the css will be cachable
[07:22] <stub> (upload a new hackergotchi and your hackergochi gets a new URL)
[07:22] <lifeless> so I think there are two important cases
[07:22] <lifeless> one is 'Pages change when I change login'.
[07:22] <lifeless> another is 'dynamic content just changed may not show until I refresh.'
[07:23] <lifeless> (consider that the pathological case is me being on a page already when you change the content behind it)
[07:24] <lifeless> fixing the first one (emit vary: Cookie) will solve the user frustation case, as 'refresh' is part of the web user experience and expectations, but 'refresh on login' is not.
[07:25] <stub> If I submit a new bug, I expect that bug to show on my 'bugs I care about' list.
[07:25] <stub> I don't know if it is reasonable to expect users to refresh
[07:28] <stub> Which would happen if I emit Vary: Cookie for all HTML pages.
[07:29] <stub> (and nearly all HTML pages change on login, as links disappear and change depending on your rights)
[07:30] <stub> Vary: *  would be correct, but will likely cause browsers to be too aggressive...
[07:32] <lifeless> stub: less aggressive than Expires: <now>
[07:33] <lifeless> Vary: * lets browsers discriminate between 'back' and 'forwards'
[07:33] <lifeless> so as a strawman, listing pages could be '*"
[07:33] <lifeless> queries could be '*, expires: <now>'
[07:34] <lifeless> front page could be 'vary: cookie'
[07:34] <lifeless> its really just a matter of deciding on the refreshness constraints we are happy with. Once *that* is decided, we can craft caching rules to match, including must-revalidate, vary, and expires headers.
[07:53] <stub> I think we can define 3 or 4 cases (update on login, update always, volatile). I'll talk to SteveA later about how a page registers its preferred caching scheme. We can then make Launchpad emit the headers we define for scheme that is selected, and a default. Although initially we can just hard code 'Vary: *' to fix issues now and tune later.
[08:12] <SteveA> right now i'm concerned mostly about the login case
[08:13] <SteveA> and, i actually have code on a (converted) branch that handles it, as a prototype spike
[08:41] <stub> SteveA: How does that branch handle the login case? Set a Vary: * header or similar as discussed above?
[08:42] <jamesh> Vary: Cookie
[08:43] <jamesh> most pages should be "Vary: Cookie", actually
[08:46] <stub> Vary cookie means that database changes will not be seen. eg. add a bug, go to your bugs screen, and it won't be there because the cookie has not changed since your last view
[08:47] <stub> (?)
[08:52] <jamesh> stub: no
[08:52] <jamesh> stub: it just tells a cache that it can't consider its version of a page valid if the request includes a different "Cookie" header
[08:52] <jamesh> it doesn't say "if the Cookie header remains constant, then the returned content will also be the same"
[08:55] <stub> jamesh: No - it says if the cookie header remains constant then you are welcome to use your cached version, which may give the effect I mentioned
[08:56] <stub> Or at least, that will be the effect (just not-ing your first statement)
[08:57] <stub> (not that I have a clue how real browsers interpret it)
[08:57] <jamesh> stub: see the "while the response is fresh" bit
[08:58] <sivang> morning all
[08:58] <spiv> stub: But that's true at the moment with Vary: Cookie too.  As far as I can tell, except for the very few static files served by the launchpad webapp, Vary: Cookie would be an improvement on the current situation.
[08:58] <jamesh> it is a little immaterial right now, since we don't provide a web browser or cache a way to tell whether a resource is fresh
[08:59] <spiv> s/at the moment with/at the moment without/
[08:59] <jamesh> stub: we'd need to be providing expiry information for browsers to decide whether the resource is fresh
[08:59] <spiv> Stupid fingers :)
[08:59] <stub> Only stuff starting with /++resource or /@@/ can ever be considered fresh We need to add the relevant headers.
[08:59] <jamesh> or enough information for them to guess: e.g. the Last-Modified header
[09:00] <lifeless> stub: I think you are missing the fact that fresh content is usually not cached for more than a second or two
[09:00] <jamesh> stub: stuff served with the static resource view sends enough information to allow proper caching
[09:00] <SteveA> stub: it sets the Vary header on a special variable cookie that is used only for logging in
[09:01] <jamesh> SteveA: doesn't the Vary header work in terms of other header names rather than cookie values?
[09:01] <jamesh> s/cookie values/cookie names/
[09:02] <stub> So what is the suggestion re: Bug 2162 (which is not just the front page, but every dynamically generated page to some extent)?
[09:02] <lifeless> jamesh: its a header-value check
[09:02] <Ubugtu> Malone bug #2162: front page cached In: launchpad (upstream), Severity: Normal, Assigned to: Stuart Bishop, Status: Accepted https://launchpad.net/bugs/2162
[09:02] <lifeless> jamesh: for the listed headers, has the value changed? No -> fresh is ok. Yes -> must revalidate/reretrieve
[09:03] <jamesh> lifeless: that's what I thought.  SteveA said he was setting the Vary header on a particular cookie
[09:04] <jamesh> which I don't think is possible
[09:04] <carlos> morning
[09:04] <jamesh> the heavy use of portlets makes it difficult to work out what is cacheable too
[09:05] <SteveA> jamesh: the way the authentication works generally, the cookie never changes
[09:06] <SteveA> jamesh: so i need to add a new cookie to make the cookie header change at all
[09:06] <SteveA> i could change the zope3 session stuff, but this is easier and less tightly coupled too
[09:06] <jamesh> SteveA: what I am saying is that you'll either be able to say the resource varies if "the cookie header changes" rather than if "a particular cookie changes"
[09:07] <jamesh> so it's an assertion about all cookies for the site
[09:07] <SteveA> i have one cookie that is used as a change marker
[09:07] <SteveA> the others don't change
[09:08] <SteveA> and an add-on to the Request / Response to say "something has changed"
[09:08] <SteveA> which increments the cookie's value
[09:08] <SteveA> this can be extended to things other than logging in
[09:09] <jamesh> SteveA: I don't think the HTTP Vary header will work at that level for you
[09:09] <SteveA> we can have an event listener or some such that notices when things change, or pages have been visited that deserve variability
[09:09] <SteveA> and changes this cookie
[09:09] <jamesh> if you put "Vary: Cookie", a cache will think it's copy of the resource is invalid if you change one cookie or all cookies
[09:09] <SteveA> the Vary header is always sent
[09:09] <SteveA> exactly
[09:10] <SteveA> there is only one cookie that we change
[09:10] <SteveA> there are two cookies needed: 1. session, 2. change
[09:10] <lifeless> spiv: has your branch for the map generation been merged to rf ?
[09:10] <SteveA> the session cookie never changes
[09:10] <jamesh> okay.  That makes sense
[09:10] <SteveA> the change cookie changes when there's been a change
[09:11] <jamesh> The other way to handle some of this stuff would be to use ESI, to construct the pages outside of the app server
[09:11] <SteveA> that may be a good thing for portlets, eventually
[09:12] <jamesh> such that we can define the caching characteristics of each page fragment easily
[09:13] <SteveA> there are issues around transactions, though
[09:13] <SteveA> so, we'd probably want to have some portlets rendered inline even then
[09:13] <SteveA> so that the data comes from the same transaction as the main page
[09:13] <lifeless> mmm esi.
[09:13] <lifeless> I loike ESi
[09:14] <SteveA> lifeless: i'll prod 1332 in RT
[09:15] <spiv> lifeless: Not yet.  Give me a moment to take another look over it, and I'll put it up for review.
[09:15] <SteveA> ...when it reaches the launchpad queue
[09:20] <jamesh> a new "msgctxt" directive to go with "msgid" and "msgstr"
[09:34] <sivang> hannosch: just use mutt ;-)
[09:35] <SteveA> hannosch: can you forward me one of the emails?
[09:37] <SteveA> hannosch: steve @ canonical.com
[09:37] <hannosch> SteveA: sure
[09:40] <SteveA> thanks hannosch.  i have the email.  i'll talk with the rosetta team about your suggestion of one email per tarball.
[09:40] <SteveA> do you want to be subscribed to the bug about it?
[09:41] <SteveA> BjornT, stub: henrik had an interesting idea about bug watches
[09:41] <hannosch> SteveA: great. yeah subscribe me please. my account at launchpad is hannosch
[09:41] <SteveA> that is to add a malone email address as a CC to a bug in an external bug tracker, and use this as a "push watch" kind of thing
[09:42] <SteveA> also, there would be no need to explicitly register the watch in launchpad, perhaps
[09:42] <SteveA> this, along with some kind of keywords, would make the accessibility stuff easier.  they want to record the status of a disparate bunch of upstream bugs.
[09:42] <SteveA> in upstream bugtrackers
[09:44] <BjornT> SteveA: yeah, doko had the same idea. i would think that we still would have to register the bugwatch explictly, though, to make the connection.
[09:44] <sivang> SteveA: sounds nice, then we'd need ot have a list of whitelisted  external bugtrackers URLs that lp would be willing to accept emails from ?
[09:44] <BjornT> we do have scripts that should update bugwatch status, though, but i'm not sure if they are working or not. we definitely should take a closer look at bug watches soon.
[09:45] <BjornT> anyway, gotta go now
[09:46] <SteveA><EMAIL_ADDRESS>might do it
[09:46] <SteveA> and just have a magic black box interpret the bug information and route it to the right launchpad bug
[09:48] <carlos> jordi, hi, around?
[09:52] <SteveA> hi carlos
[09:52] <carlos> SteveA, hi
[09:53] <SteveA> can we make the tarball imports send a single email listing the files, and giving the success or failure of each?
[09:54] <SteveA> the rosetta user hannosch received a large number of emails as a result of importing a tarball
[09:54] <carlos> Hmm, we would need then a way to store the import status
[09:55] <carlos> every file is imported as a different process
[09:55] <carlos> or perhaps change our script to group the imports by importer....
[09:55] <carlos> yes, this solution is better...
[09:58] <stub> SteveA: Interesting idea. We will need to allow 'anonymous comments' though in Malone (comments from email addresses not registered with Launchpad).
[10:05] <lifeless> reviewwe meeting time!
[10:05] <SteveA> stub: i imagine we would have a special case for bugs from these bugtrackers
[10:05] <lifeless> whos here ?
[10:05] <SteveA> spiv: phone call after the review team meeting?
[10:05] <SteveA> i'm here
[10:05] <lifeless> jamesh:, salgado:, bjornt:, spiv: here ?
[10:06] <stub> SteveA: That assume we know what they are - if we just allow anonymous comments coming in, no registration of external bug trackers is needed for it. Just might be a spam problem.
[10:07] <jblack> daf: ping
[10:08] <spiv> I'm here.
[10:08] <spiv> SteveA: Sure.
[10:09] <jblack> daf: unping
[10:09] <carlos> Untriaged  (0)
[10:09] <carlos> Finally!! :-D
[10:09] <jblack> we have a bot here, no?
[10:09] <lifeless> ok
[10:09] <lifeless> 3's enough to start :)
[10:09] <lifeless> and we're a bit late.
[10:09] <lifeless> agenda:
[10:09] <lifeless> -------
[10:09] <jblack> Wouldn't it be cool if the bot watched pings and unpings?
[10:10] <lifeless> roll call
[10:10] <lifeless> next meeting
[10:10] <lifeless> any last minute requests ?
[10:10] <jamesh> lifeless: yeah
[10:10] <lifeless> ...
[10:11] <jamesh> (that's yes I'm here, not last minute requests)
[10:11] <lifeless> ok
[10:11] <lifeless> any last minute requests ?
[10:12] <lifeless> ok, meeting over.
[10:12] <lifeless> next meeting, will be jan 4th 0900 UTC
[10:12] <lifeless> thanks for you attention ;)
[10:12] <sivang> lifeless: what meeting was that? :-) (wow that was *quick*)
[10:13] <spiv> lifeless: Not a problem ;)
[10:15] <spiv> SteveA: call time?
[10:16] <lifeless> sivang: ReviewerMeetingAgenda on the wiki
[10:17] <stub> Bug 5814
[10:17] <Ubugtu> Malone bug #5814: want to know breakdown of test run time by area of development In: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Accepted https://launchpad.net/bugs/5814
[10:18] <SteveA> spiv: sure, let me find my phone...
[10:20] <spiv> SteveA: my landline is best.
[10:31] <stub> SteveA: Are you looking at Z3.1 this week? I have some stuff to do with the test suite and am wondering if I should put it off until next week.
[10:37] <stub> Ooh... looks like it already does everything I need...
[10:44] <siretart> does lauchpad have a development mailing list?
[10:44] <siretart> please tell me the contact address
[10:44] <jamesh> siretart: yes
[10:45] <daf> BjornT: carlos and I got a bit confused because we were seeing different numbers of open bugs in Malone
[10:45] <daf> BjornT: we worked out that it was because I'm not logged in, and it wasn't counting private bugs for me
[10:45] <daf> BjornT: is that deliberate?
[10:46] <jamesh> siretart: it is currently a closed subscription list
[10:47] <daf> does the launchpad-users list exist yet?
[10:47] <siretart> http://lists.ubuntu.com/mailman/listinfo/launchpad-users
[10:47] <siretart> looks like
[10:47] <siretart> no posts yet, though.
[10:47] <BjornT> daf: yes, but i agree that it can be confusing. maybe we should list number of public and private separately, so that it's more clear.
[10:48] <jamesh> siretart: the users list is open subscription, yes
[10:49] <carlos> BjornT, I think that's a good idea
[10:49] <siretart> jamesh: I just CC:ed it
[10:49] <daf> BjornT: hmm, I think that might be an unnecessary complexity
[10:49] <siretart> gnarf
[10:49] <daf> BjornT: is there a security benefit to not giving un-logged-in users the full counts?
[10:50] <siretart> damn semi-moderated mailing lists ;)
[10:51] <carlos> BjornT, we found another UI problem with Malone, I suppose it's a bug...
[10:51] <carlos> BjornT, daf sees https://launchpad.net/products/rosetta/+bug/744 bug as untriaged (that's correct)
[10:51] <daf> daf files a private bug
[10:51] <daf> carlos triages bugs
[10:51] <Ubugtu> Error: I cannot access this bug
[10:52] <carlos> BjornT, but I don't see it
[10:52] <daf> carlos doesn't see the private bug as one that needs triaging
[10:52] <carlos> as untriaged
[10:52] <daf> because he's not subscribed to it
[10:52] <carlos> but I can read the bug report
[10:52] <carlos> so I have access to it
[10:54] <jblack> lifeless: ping
[10:55] <BjornT> daf: well, when i said we should list both counts, i was referring to the bug listings only. it's confusing if it says '1 -> 20 of 369' if you can see all the bugs. then again, that number is dependant of search text, which can be a security issue...
[10:55] <daf> oh, I see
[10:55] <daf> I was only thinking about the portlet with the different numbers in it
[10:57] <BjornT> yeah, in the portlet it would be ok to list private bugs as well, but it's hard to get it right. both public and private counts take up too much space, and including private bugs that you can't see can be confusing.
[10:58] <BjornT> i hope this will be less of a problem when we get more persistent logins, so that you can stay logged in for a longer period of time.
[10:58] <daf> mmm
[10:58] <daf> it is a tricky problem
[11:00] <stub> persistent logins won't happen until someone reviews my PostgreSQL sessions branch
[11:05] <BjornT> stub: that branch is currently in salgado's queue. you can nag him about it, and if he hasn't time, he can put in my queue and i'll review it tomorrow.
[11:09] <BjornT> time to board the plane, see you later
[11:15] <lifeless> jblack: pong
[11:20] <stub> Kinnison: Do you need the staging database in its current state, or can I resync it from production?
[11:21] <jamesh> so gina's going to be run in production sometime soon?
[11:22] <stub> jamesh: It is running now
[11:23] <lifeless> wooyeah
[11:23] <stub> jamesh: So bugzilla migration can happen if you are happy with the scripts
[11:23] <lifeless> elmo: Znarl: either of you ping
[11:25] <jamesh> stub: yay.
[11:25] <jamesh> we'll need to turn off write access to bugzilla before that happens though.
[11:26] <jamesh> also need to check with bradb re: InitialBugContacts
[11:29] <stub> debugs syncing too...
[11:29] <stub> I wonder if that is still working...
[11:30] <Znarl> lifeless : Pong
[11:31] <lifeless> Znarl: rt 1332
[11:31] <lifeless> Znarl: thats highly urgent please.
[11:31] <stub> jamesh: How is your schedule looking? Someone will need to test out the debugs code to ensure it still does the right thing, and I expect that is either me or you.
[11:31] <lifeless> Znarl: I realise you've probably just woken up.
[11:31] <lifeless> Znarl: it wasn't quite urgent enough to wake you guys
[11:32] <Znarl> lifeless : My work day started an hour and a half ago.
[11:32] <lifeless> Znarl: oh, oh :)
[11:35] <jblack_> znarl: Cool, you're here. Can I talk to you for a moment?
[11:35] <Znarl> jblack : Once I deal with lifeless's request, unless it's urgent.
[11:36] <lifeless> jblack_: I need to talk about the other mapping script with you
[11:36] <jamesh> stub: when I last looked at that code, it seemed to only handle creating new bugs from deb bugs (only copying the initial debbugs comment), and status synching
[11:36] <jblack_> znarl: Lifeless first. I'll talk with lifeless in the meantime. :)
[11:36] <jamesh> stub: it'll probably need a bit more work to do full comment synching like debzilla did
[11:36] <jamesh> (although it should be possible to do better, since we keep track of message IDs)
[11:38] <jblack_> lifeless: that hash doesnt' look like it breaks up well.
[11:38] <lifeless> jblack_: its not a hash
[11:38] <lifeless> jblack_: it has high locality of reference, which is desirable
[11:38] <jblack_> Ok. if its wanted.
[11:39] <stub> jamesh: Mark was happy with what he is written, so we just need to ensure his code is still working - extra features are later. I'm aware of at least one issue to fix (it is connecting as the wrong db user)
[11:43] <jamesh> stub: okay.  The first thing to do would probably be to add some tests to make sure it works and doesn't get broken again
[11:45] <jblack> lifeless: hi
[11:46] <lifeless> hi
[11:46] <jblack> I have unchanged this:
[11:46] <jblack> from /%d/%d/%d/%d to /%d/%d/%d/%d/launchpad id
[11:47] <lifeless> it *was* %d/%d/%d/%d .
[11:47] <lifeless> thats what it should be
[11:47] <jblack> It _is_ that. :)
[11:47] <lifeless> great.
[11:47] <jblack> I put it back as soon as you said.
[11:47] <lifeless> That *IS* the launchpad id.
[11:48] <lifeless> thank you.
[11:48] <jblack> I suppose 4 billion products is enough for anyone. :)
[11:48] <lifeless> well
[11:48] <lifeless> we dont show the launchpad id to the user
[11:48] <lifeless> so we can just update our disk format at 3.99999 billion
[11:48] <jblack> The formula itself will need a change.
[11:48] <jblack> but yeah.
[11:49] <jblack> I'm reading it now, we're fine for my lifetime. :)
[11:50] <jblack> Actually, even longer than that. It fails gracefully
[11:50] <jblack> I lied. it doesn't.
[11:50] <jblack>     hex = "%08x" % int(branchnum)
[11:51] <lifeless> its fiiiine
[11:51] <jblack> It fails on the hundred millionth exactly.
[11:51] <lifeless> we'll have to adjust postgresql way before then
[11:52] <daf> back in about 90 minutes, I think
[11:52] <lifeless> stub: we have a script that is not yet in rf main that I'd like to roll out today on gangotri
[11:52] <jblack> ok
[11:52] <jblack> I still have a bug when it comes to nonexistant branches that I need to fix.
[11:52] <stub> lifeless: Just a single script, or does it need a full launchpad update?
[11:53] <lifeless> stub: it needs  anew lp branch
[11:53] <jblack> I also think I have one on the lockfile
[11:53] <lifeless> stub: I'm inclined to do a separate checkout for now
[11:53] <stub> ok
[11:53] <lifeless> stub: is that ok with you?
[11:53] <stub> Sure - seperate directory won't affect production in any way
[11:54] <lifeless> vanessa ?
[11:54] <lifeless> stub: parallel to the production dir ?
[11:55] <stub> lifeless: Yes - /srv/launchpad.net/somethingnew
[11:56] <stub> Znarl: You remember the name of the new Launchpad appserver that we currently arn't using? I think ddaa had bzrsync stuff on there.
[11:58] <Znarl> stub : Mmm..
[11:59] <Znarl> stub : Gandwana?
[12:04] <stub> Yup - looks like it
[12:13] <lifeless> thats appserver 2 ?
[12:17] <jordi> carlos: here
[12:18] <carlos> jordi, don't worry, it was about the tin template request
[12:18] <carlos> I assigned you that bug
[12:18] <jordi> nod
[12:18] <carlos> so feel free to close it if you already fixed it
[12:18] <jordi> not yet
[12:26] <matsubara> good morning!
[12:27] <SteveA> jamesh: bugzilla import: is it importing just open bugs, or all bugs?
[12:27] <jamesh> SteveA: all bugs
[12:28] <sivang> hi matsubara
[12:28] <stub> lifeless: Yes - appserver 2. Running breezy so we are not using it yet. I'll switch it on after staging is happy on breezy.
[12:29] <sivang> matsubara: I still didn't manage to attend to that bug, hopefully will do so this evening.
[12:31] <matsubara> sivang: no problem. I'm working on another one instead.
[12:32] <lifeless> stub: ak
[12:32] <lifeless> ack
[12:36] <stub> Yay testdisconnects pqm failures
[12:49] <lifeless> stub: ?
[12:49] <lifeless> stub: is there a stale process as pqm ?
[12:50] <lifeless> spiv: ping
[12:50] <spiv> lifeless: pong
[12:50] <stub> lifeless: Not that I can see
[12:50] <lifeless> stub: weird
[12:50] <lifeless> spiv: should I hack the cronscript to call rsync ?
[12:50] <lifeless> spiv: via 'system' ?
[12:50] <lifeless> spiv: and what frequency do you suggest ?
[12:51] <spiv> Hmm, I'm not sure what's the best taste for the rsync step.  I'd be tempted to make it part of the cron line rather than part of the script.
[12:51] <spiv> For frequency, how about 1 hour (to pick a random value :) ?
[12:51] <lifeless> spiv: via && ? ewww
[12:51] <salgado> cprov, Should we allow mirrors to have an httpbaseurl, an ftpbaseurl and an rsyncbaseurl at the same time or are they mutually exclusive?
[12:52] <spiv> The script should be quick fast, it's database needs are fairly simple.
[12:52] <spiv> s/quick/quite/
[12:53] <spiv> (It could almost certainly be made faster with a single explicit SQL statement rather than the current SQLObject code, if needed).
[12:53] <jblack> lifeless: How do you want to expose via launchpad id to ddaa? A rewrite rule?
[12:53] <lifeless> jblack: there is a rewrite mapping already given to you
[12:53] <jblack> Two, actually. Those two are in
[12:53] <cprov> salgado: yes, they can have those 3 access methods at the same time, unfortunately we can only check HTTP properly
[12:54] <lifeless> jblack: right, I need to know what they look like and what hostname they are on, to answer ddaa's question
[12:54] <lifeless> spiv: the reason to put it in the script is to eliminate the tempfilename issue
[12:54] <jblack> I believe ddaa wants /+branches/lpid
[12:54] <lifeless> spiv: consider it a bug report :)
[12:54] <lifeless> jblack: he doesn't care about the prefix
[12:54] <jamesh> SteveA: one other thing I just thought of w.r.t. bugzilla migration: it might be worth trying to generate an apache mod_rewrite map to redirect show_bug.cgi-style URLs to the corresponding Launchpad page
[12:54] <spiv> lifeless: tempfile(1)
[12:54] <lifeless> jblack: just needs to know
[12:54] <elmo> lifeless: I'm confused you already have a private launchpad port open - can the file not be transferred via that?
[12:54] <jblack> We currently have these two:
[12:54] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[12:54] <jblack>   RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/
[12:55] <lifeless> spiv: I am so not putting all that in crontab. Which means another script. Which may as well be python
[12:55] <lifeless> elmo: different behaviour, this is conceptually able to be pushed on-demand, the pull behaviour occurs via cron
[12:56] <elmo> lifeless: ok, define high priority - do I need to drop everything else I'm doing or can it wait till this evening?
[12:56] <lifeless> elmo: but yes, we can in theory do that in the future, though I'm not sure it fits the problem well.
[12:56] <lifeless> elmo: I'd *like* to have this working before I go to bed.
[12:56] <elmo> lifeless: well, I'm super not keen on ssh in either direction - will normal rsync do?
[12:56] <lifeless> elmo: it was not 'wake you and znarl up' when we noticed at 11am.
[12:56] <lifeless> rsync is all we need
[12:57] <lifeless> my documentation was in hindsight unclear. Heres a clearer statement
[12:57] <lifeless> rsync outputfile
[12:57] <lifeless> bah
[12:57] <lifeless> rsync afile vostok.ubuntu.com[whateveryouwanthere] :/srv/sm-ng/config/launchpad-lookup.txt
[12:57] <lifeless> ^ if that works from the user launchpad on gangotri, I am happy.
[12:58] <elmo> ok
[12:59] <lifeless> spiv: you have a question in email
[12:59] <spiv> Ok.
[01:00] <lifeless> jblack: that second rule is the interesting one, it seems inactive
[01:00] <lifeless> spiv: ^^
[01:00] <jblack> lifeless: yeah
[01:00] <jblack>   RewriteRule ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ branches/$1/$2/$3/$4/
[01:00] <jblack> I suspect it should be:
[01:00] <jblack> ^branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:00] <lifeless> ok
[01:00] <lifeless> lets try that
[01:01] <jblack> k
[01:01] <jblack> mind if I change that to Rewriterule ^\+branches as well?
[01:02] <lifeless> works for me
[01:02] <lifeless> I'd actually like this on a new VHost if possible
[01:02] <lifeless> so that it does not expose to the outside at all
[01:02] <lifeless> but that can wait for once its all working in whatever form
[01:02] <jblack> Thats no problem to me... what do you want for a hostname?
[01:02] <jblack> oh, ok
[01:05] <jblack> elmo: how do I reload apache on vostok?
[01:05] <jblack> You gave me sudo access for it a while back, but I've since forgotten which script it was.
[01:06] <elmo> jblack: I don't think I ever did for  vostok
[01:07] <jblack> ah. mind reloading apache2 on vostok for me?
[01:07] <Znarl> jblack : I checked this a while ago, you can't reload apache I believe.
[01:07] <elmo> jblack: sudo apache2ctl graceful
[01:08] <elmo> jblack: but at some stage (just not today or this week) we may need to revisit this and how slack we/I've gotten WRT permissions on vostok ;)
[01:09] <jblack> Yeah. We need that conversation. I'd like it really soon though, because not having ssh access to the supermirror account is causing heck on rollout.
[01:09] <lifeless> ok,
[01:09] <lifeless> more cron spam
[01:09] <lifeless> spiv: may want to disable the 'info lockfile acquired' :)
[01:24] <lifeless> jblack: how you going with that redirect
[01:24] <jblack> I'm trying.
[01:24] <lifeless> jblack: I get infinite redirect now
[01:24] <jblack> I have this:
[01:24] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ /\+branches/${branch-list:$1}/
[01:24] <jblack>   RewriteRule ^/\+branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:25] <jblack> which gives me this: [Wed Dec 21 12:25:06 2005]  [error]  [client <IP_ADDRESS>]  File does not exist: /srv/sm-ng/mirrors/+branches
[01:26] <jblack> oh, duh
[01:26] <lifeless> ok
[01:26] <lifeless> ^\+branches
[01:26] <jblack> The first rule gobles up .*
[01:26] <lifeless> I think is what you want
[01:27] <lifeless> shouldn't
[01:28] <lifeless> it needs ~
[01:28] <lifeless> so the it wonter interact
[01:28] <lifeless> no I think the problem is the leadng /
[01:28] <elmo> lifeless: rsync target is launchpad@bazaar.launchpad.net::config/launchpad-lookup.txt
[01:28] <elmo> lifeless: password is in /srv/launchpad.net/rsync-password
[01:28] <elmo> WFM
[01:29] <elmo> NB: you need to use b.lp.net, not vostok (and that's a feature)
[01:29] <lifeless> ok
[01:29] <elmo> lifeless: also be careful of permissions on vostok, they're delicate, but will do for now
[01:29] <elmo> I'm AFK for a bit, but please shout soon if it's not sufficent as I have to go to the DC
[01:29] <lifeless> elmo: how do I tell rsync the password ?
[01:30] <lifeless> elmo<EMAIL_ADDRESS>?
[01:30] <jblack> Nope, that didn't do it. Nor did ^\\+
[01:30] <lifeless> jblack: I know that spiv tested this
[01:30] <elmo> lifeless: RSYNC_PASSWORD or --password-file
[01:30] <lifeless> jblack: so lets reset to what he had.
[01:31] <elmo> lifeless: (btw, I didn't intend that rsync-password file to be final, it's just a temporary thing, if you keep it in a file, please put it somewhere more sane :)
[01:31] <lifeless> elmo: oh, ok
[01:31] <lifeless> uhm crontab safe enough ?
[01:32] <elmo> yeah
[01:36] <lifeless> ok
[01:36] <lifeless> jblack: can you check launchpad-lookup.txt
[01:36] <lifeless> it should be valid now
[01:36] <lifeless> elmo: thank you hugely
[01:36] <jblack> lifeless: Looks like it has useful data
[01:37] <lifeless> jblack: ok
[01:37] <lifeless> jblack: ok, show me your current rewrite rules ?
[01:38] <jblack> I've disabld that one for the moment
[01:38] <lifeless> ok, can we go back to what you had an hour ago ?
[01:38] <lifeless> i.e. both enabled, with spivs values which we know to be wrong ;)
[01:40] <jblack> I'm guessing that you're not aware that I'm talking to spiv
[01:40] <lifeless> I'm not
[01:40] <lifeless> may I suggest this channelo
[01:40] <lifeless> is an appropriate forum
[01:41] <jblack> Ok. I've got progress. ;)
[01:41] <jblack> Of a sort.
[01:41] <jblack> The / is necesasry.
[01:41] <lifeless> what do you mean 'of a sort' ?
[01:42] <jblack> The rewrite rule is rewriting
[01:42] <jblack> However, its rewriting the wrong thingh
[01:42] <lifeless> show me ?
[01:42] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:42:45 +0000]  [bazaar.launchpad.net/sid#80b7f30] [rid#81961e0/initial]  (2) prefixed with document_root to /srv/sm-ng/mirrors/00/00/05/31/
[01:42] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:42:45 +0000]  [bazaar.launchpad.net/sid#80b7f30] [rid#81961e0/initial]  (1) go-ahead with /srv/sm-ng/mirrors/00/00/05/31/ [OK]
[01:43] <lifeless> the rule I meant :)
[01:43] <jblack> oh
[01:43] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[01:43] <jblack>   RewriteRule ^/branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:44] <jblack> All of the branches sm-mg writes are in /srv/sm-ng/mirrors/00/00/02/...
[01:44] <lifeless> ok
[01:44] <lifeless> the doc root is /src/sm-ng/mirrors to right ?
[01:44] <jblack>  /srv/sm-ng/mirrors actually
[01:45] <lifeless> yhehe
[01:45] <lifeless> thats what I meant
[01:45] <lifeless> ok.
[01:45] <spiv> I'm falling asleep.
[01:45] <lifeless> so its infinitely redirecting
[01:45] <lifeless> which is a two-step problem
[01:45] <jblack> I get 404s
[01:45] <spiv> Good luck :)
[01:46] <lifeless> the first step is that something is issueing 302s
[01:46] <lifeless> spiv: did you have this working ?
[01:46] <spiv> lifeless: On my local system, yes.
[01:46] <lifeless> spiv: differences ?
[01:46] <spiv> My email gave all the information that seemed relevant to me.
[01:46] <jblack> The url needed for launchpad id lookup is  /branches/00000531/
[01:46] <spiv> lifeless: Sorry, I'm just too tired to be helpful right now.
[01:46] <lifeless> spiv: ok, np
[01:47] <lifeless> jblack: lets focus on the name mapping first
[01:47] <jblack> sure
[01:47] <lifeless> what does http://bazaar.launchpad.net/~mdz/ltsp/ubuntu-main/ generate for youo, and whats the rewrite rule for it ?
[01:49] <jblack> Heh. Lets slow up for a moment?
[01:49] <lifeless> jblack: ok
[01:49] <jblack> The problem with the infinit redirect is the two rewrite rules
[01:50] <lifeless> ok. comment out the one for b.l.p/xxxxxxxx
[01:50] <lifeless> (because if that goes on a different vhost anyway, it wont be an issue)
[01:51] <jblack> done
[01:51] <lifeless> ok
[01:51] <lifeless> so whats the other rewrite rulle look like ?
[01:51] <jblack> #  RewriteRule ^\/branches/([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})([[:xdigit:] ] {2})/ /$1/$2/$3/$4/
[01:52] <lifeless> sorry, the uncommented one
[01:52] <jblack>   RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ branches/${branch-list:$1}/
[01:52] <lifeless> ok
[01:52] <lifeless> can you change that to
[01:52] <lifeless> RewriteRule ^(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:52] <jblack> sure.
[01:53] <jblack> I think its missing a leading /
[01:53] <lifeless> well
[01:53] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:53:27 +0000]  [bazaar.launchpad.net/sid#80d1f98] [rid#81cf200/initial]  (1) pass through /~mdz/ltsp/ubuntu-main/
[01:53] <lifeless> ok
[01:53] <lifeless> so lets add
[01:54] <lifeless> RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:54] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:54:03 +0000]  [bazaar.launchpad.net/sid#80c9f78] [rid#81800b0/initial]  (2) local path result: 00/00/02/13/
[01:54] <jblack> Thats not what I did actually
[01:54] <lifeless> what did you do ?
[01:54] <jblack>   RewriteRule ^\/(~[^/] +/[^/] +/[^/] +)/ ${branch-list:$1}/
[01:54] <jblack> but that gave a 400
[01:54] <lifeless> wont work
[01:55] <jblack> Ok. thats close
[01:55] <jblack>   RewriteRule ^/(~[^/] +/[^/] +/[^/] +)/ /${branch-list:$1}/
[01:55] <lifeless> ok
[01:55] <jblack> Its looping still
[01:55] <lifeless> now its directing blarh/ to blarh/index.html
[01:56] <jblack> Yeah
[01:56] <lifeless> and that is missing
[01:56] <lifeless> whats strange is the repeat redirect
[01:56] <lifeless> theres something else in your config causing this
[01:57] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:56:50 +0000]  [bazaar.launchpad.net/sid#80b9f38] [rid#8197100/subreq]  (2) prefixed with document_root to /srv/sm-ng/mirrors/00/00/02/13/
[01:57] <jblack> <IP_ADDRESS> - - [21/Dec/2005:12:56:50 +0000]  [bazaar.launchpad.net/sid#80b9f38] [rid#8197100/subreq]  (1) go-ahead with /srv/sm-ng/mirrors/00/00/02/13/ [OK]
[01:57] <jblack> I think the redirect is catching again
[01:57] <lifeless> no
[01:57] <lifeless> it cant match, theres no ~
[01:57] <lifeless> its sending replies to the browser
[01:58] <lifeless> I've checked with tethereal
[01:58] <daf> SteveA: around?
[01:59] <jblack> I'll happily paste you the whole virtualhost directive in msg
[01:59] <lifeless> might be in the default section
[01:59] <lifeless> which affects all vhosts
[01:59] <jblack> That'll take elmo. Thats outside of my control
[01:59] <SteveA> daf: yes
[01:59] <lifeless> this is what happens
[01:59] <lifeless> GET /~mdz/ltsp/ubuntu-main/ HTTP/1.1\r\n
[02:00] <lifeless>     HTTP/1.1 301 Moved Permanently\r\n
[02:00] <lifeless> ..
[02:00] <lifeless> Location: http://bazaar.launchpad.net/~mdz/ltsp/ubuntu-main/index.html/\r\n
[02:00] <lifeless> thats a different rule kicking in
[02:00] <lifeless> now
[02:00] <daf> SteveA: carlos and I have triaged all the bugs in Rosetta
[02:01] <lifeless> branch-format is kicking this in too
[02:01] <daf> SteveA: we're left with 106 open bugs
[02:01] <jblack> oh, I may know
[02:01] <lifeless> one sec
[02:01] <lifeless> oh?
[02:01] <daf> SteveA: we're wondering if you had any ideas about how to go about prioritising them
[02:01] <jblack> No.
[02:01] <lifeless> ok
[02:01] <lifeless> paste it to me baby!
[02:01] <jblack> sure
[02:02] <jblack> msg me?
[02:03] <SteveA> stub, jamesh: https://wiki.launchpad.canonical.com/BugzillaImportProcess
[02:04] <lifeless> jblack: done
[02:04] <jblack> you're done with what?
[02:04] <lifeless> I msged you
[02:04] <jblack> I didn't see anything from you
[02:05] <SteveA> daf: how about you and i do a voice call to talk through the bugs?
[02:05] <lifeless> msged again
[02:05] <stub> ack
[02:05] <SteveA> it would be nice to have carlos involved, but i think three people would make things slower
[02:05] <daf> yes
[02:05] <daf> I agree
[02:05] <SteveA> we can call out to carlos on irc later for tricky questions
[02:06] <daf> and the conferencing stuff doesn't seem to reliable anyhow
[02:06] <daf> * too
[02:06] <SteveA> it wasn't so bad once we got it going
[02:06] <SteveA> although carlos' voice kept breaking up for me
[02:06] <daf> likwise
[02:06] <daf> and getting it going did take some time
[02:07] <SteveA> this is true
[02:07] <SteveA> carlos, daf: is there a bug about sending email once for a whole tarball import?
[02:08] <daf> not that I know of
[02:08] <daf> is that a bug?
[02:08] <SteveA> a user uploading one tarball
[02:08] <SteveA> and later receiving 250 emails
[02:08] <SteveA> is a bug
[02:09] <SteveA> a single action should not result in such a response
[02:09] <daf> oh
[02:09] <daf> I got the impression from what you said that the problem was opposite
[02:09] <daf> yes, that is a bug
[02:09] <SteveA> http://people.ubuntu.com/~fabbione/irclogs/launchpad-current.html
[02:09] <SteveA> see today's log, seach for hannosch
[02:09] <SteveA> hannosch would like to be subscribed to that bug
[02:10] <daf> I think few enough people have tried to use the tarball upload that they haven't complained much
[02:11] <daf> hmm, I was trying to get a list of all 121 open bugs at once by setting batch_start and batch_end by hand
[02:11] <daf> but that doesn't seem to work: it just gives me 20 from batch_start
[02:11] <SteveA> i think there is a malone bug on that
[02:12] <SteveA> there should be a hardcoded absolute limit
[02:12] <SteveA> although, even that isn't needed now
[02:12] <SteveA> because we have timeouts on long queries / expensive pages
[02:12] <daf> indeed
[02:12] <SteveA> so, people should be able to change the batch boundaries
[02:13] <stub> Within limits, or else people are just going to engineer timeouts
[02:14] <SteveA> i don't follow
[02:14] <SteveA> if someone gets a timeout, then the page doesn't work
[02:14] <SteveA> but it still isn't so expensive
[02:14] <stub> Indeed. People set their batch size to 5000, and some pages stop working
[02:14] <daf> if they file a bug, we can say "batch sizes of 5000" are not supported
[02:15] <SteveA> if they're messing with the URL directly...
[02:15] <carlos> Rosetta's translation form has a limit of 100 entries per page
[02:15] <SteveA> then they can expect that
[02:15] <daf> quite
[02:15] <stub> Batch size can be stuffed in the session and used everywhere we batch
[02:15] <SteveA> now, if we have a UI for setting prefered batch size, of course there should be limits
[02:15] <stub> Just a user preference
[02:15] <SteveA> and mpt has said in the past that there are different appropriate sizes for different things
[02:15] <carlos> daf, are you going to file that bug?
[02:15] <carlos> (the one SteveA asked)
[02:16] <daf> yes
[02:16] <daf> just as soon as I've filed this Malone bug
[02:16] <carlos> ok
[02:18] <daf> hmm, isn't there a way to search for bugs across all products?
[02:18] <SteveA> everything in a context
[02:18] <SteveA> we'll want this when we have keywords, though
[02:19] <daf> well, I was thinking that if there was an existing bug about tarballs, it might be filed against Launchpad rather than Rosetta
[02:19] <daf> so I have to search both by hand
[02:19] <SteveA> we should be able to seach within a project, at least
[02:20] <SteveA> but, it is not possible today
[02:20] <SteveA> stub: when's the code on staging going to be updated?
[02:20] <stub> erm... now?
[02:21] <stub> Kinnison: ping
[02:21] <SteveA> oh, cool
[02:21] <SteveA> i want to see how some of the recent PQM landings look
[02:24] <stub> I'll set it up for daily code updates again.
[02:24] <stub> But need to talk to Kinnison about the database
[02:24] <stub> (or is he on leave?)
[02:25] <daf> he is on leave, I believe
[02:26] <SteveA> i updated https://wiki.launchpad.canonical.com/BugzillaImportProcess
[02:27] <SteveA> stub, jamesh: maybe subscribe to it?
[02:27] <stub> ack
[02:28] <stub> Staging updated (up to r2930)
[02:30] <SteveA> hmm, the site map's CSS causes it to shift around a bit when different things are selected
[02:34] <jordi> carlos: so the "can't add people to groups" bug, it's quite important if I'm going to create and manage Translation Project teams
[02:35] <jordi> (for tin, xkbconfig etc)
[02:35] <carlos> jordi, I don't understand the issue there...
[02:35] <carlos> the owner of the team will be able to promote anyone either to member or to admin
[02:36] <jordi> carlos: I'm talking about groups, not teams
[02:36] <jordi> Translation Project, GNU Translators, etc.
[02:36] <carlos> jordi, and for the GNU teams we cannot let anyone to do it... it's a rosetta expert task
[02:36] <carlos> jordi, but there you appoint a team
[02:36] <carlos> no a list of people
[02:36] <carlos> so the owner of the team handle the people
[02:36] <jordi> carlos: ok, but a rosetta expert can't do it yet
[02:36] <jordi> I have no perms
[02:36] <carlos> jordi, ok, you cannot appoint new teams, right
[02:36] <jordi> carlos: still, I can't appoint teams
[02:37] <SteveA> daf: when do you want to do that call?
[02:37] <carlos> but If that's the issue, I think we already have that bug...
[02:37] <jordi> I just filed it
[02:37] <carlos> and it's Rosetta specific
[02:37] <carlos> no, I think it's older than one month
[02:38] <carlos> jordi, https://launchpad.net/products/rosetta/+bug/1882
[02:38] <Ubugtu> Malone bug #1882: Rosetta Experts cannot add members to existing groups In: rosetta (upstream), Severity: Major, Assigned to: Carlos Perell Marn, Status: Accepted https://launchpad.net/bugs/1882
[02:39] <carlos> jordi, so, can I set the other bug as a duplicate of this one?
[02:39] <jordi> so I filed the same bug twice..
[02:39] <carlos> right
[02:39] <carlos> jordi, you suck :-P
[02:39] <jordi> yup
[02:39] <jordi> the second one was more verbose. :)
[02:39] <carlos> ok, I will set the 1882 as the duplicate
[02:41] <daf> SteveA: hmm, not sure
[02:41] <carlos> jordi, done
[02:41] <SteveA> daf: well, i could make some food now, and we can do it in a while
[02:41] <daf> ok, I could eat too
[02:41] <SteveA> daf: how much longer do you have at work today?
[02:42] <daf> about 1:45
[02:42] <SteveA> we could both eat, and then do a couple of hours of bug conversation
[02:43] <daf> ok, sounds good
[02:56] <dilys> Merge to devel/launchpad: Implement http://wiki.launchpad.canonical.com/ProperSignUpWorkflow. r=lifeless (r2931: Guilherme Salgado)
[02:57] <stub> Gina is up to breezy with no ERRORs
[02:58] <SteveA> cool
[03:09] <jblack> elmo: still around?
[03:10] <lifeless> stub: ping
[03:10] <lifeless> stub: check gangotris crontab -e
[03:10] <lifeless> stub: for that new script entry.
[03:14] <lifeless> SteveA: FYI, branch publication of pulled branches is now live, kudos to jblack, spiv
[03:14] <jblack> partially live.
[03:14] <jblack> its not cronned yet and it breaks if a branch doesn't exist
[03:14] <lifeless> jblack: it publishes successfully pulled branches
[03:15] <lifeless> jblack: cron it man!
[03:15] <lifeless> and I'll do up a test case with you tomorrow
[03:15] <lifeless> first thing when you and I are both around
[03:15] <jblack> it publishes successfully until the first unsuccesfully pulled branch.
[03:15] <jblack> And there's a problem iwth the lockfile in that it doesn't timeout.
[03:15] <lifeless> jblack: one step at a time.
[03:15] <jblack> hit a bad one, dump. won't restart because...
[03:16] <lbm> i need an admin to help me clean up gnomebaker in launchpad, anyone?
[03:16] <jblack> yeah, one step at a time
[03:16] <lifeless> jblack: its not bug free, but it is live.
[03:16] <lifeless> live != finished
[03:16] <lifeless> you will now get feedback and questions from people, which you could not before
[03:16] <lifeless> anyhow, zzzz for me.
[03:19] <jblack> Anybody want me before I do some christmas shopping?
[03:26] <daf> SteveA: ready when you are
[03:33] <bradb> jblack: How do I unlock a branch with bzr?
[03:36] <bradb> lifeless: The --story code was already approved. The branch has been outstanding for a couple of weeks, and if I'm blocked on adding tests for --story it's unlikely that this code will land before 2006. Can I get your sign-off on landing it, if I open a High priority bug on adding a test for it?
[03:36] <SteveA> daf: hi
[03:37] <daf> SteveA: hi
[03:38] <SteveA> ready?
[03:38] <daf> yes
[04:40] <jordi> carlos: saw my addenum to the groups bug?
[04:41] <carlos> jordi, yes
[04:41] <carlos> jordi, the problem is that the system was not designed to have many translation groups
[04:41] <carlos> but it's just a matter of adding the owner concept
[04:41] <carlos> so it should not be too hard to implement
[04:43] <jordi> carlos: yup. But it's clear we need a few more than what we thought.
[04:43] <jordi> for some people it's completely necessary.
[04:44] <matsubara> salgado, stub: Could you subscribe me to the launchpad-devel mailing list?
[04:48] <carlos> jordi, yeah
[04:48] <carlos> will be back later
[04:49] <carlos> SteveA, daf do you need anything from me now?
[04:49] <carlos> I suppose I will be out for an hour or so
[04:50] <jordi> carlos: if you could answer the OOo question...
[04:50] <carlos> which OOo question?
[04:51] <lbm> carlos: you have a minute?
[04:51] <jordi> carlos: wait
[04:51] <carlos> lbm, is it really urgent? I need to leave for an hour...
[04:51] <jordi> doko answered
[04:51] <carlos> jordi, ok
[04:51] <SteveA> carlos: it's fine
[04:51] <carlos> ok
[04:51] <lbm> carlos: no, just need a little help to clean up gnomebaker in launchpad
[04:51] <lbm> carlos: will you have a minute later tonight?
[04:52] <carlos> lbm, ok
[04:52] <carlos> lbm, sure
[04:52] <carlos> lbm, anyway, talk with jordi just in case he can help you (if he has time)
[04:52] <lbm> carlos: great
[04:52] <carlos> lbm, I will ping you when I'm back
[04:52] <jordi> hey lbm
[04:52] <carlos> cheers
[04:52] <carlos> see you in an hour
[04:52] <lbm> jordi: hi, maybe you can help me
[04:53] <jordi> lbm: hopefully!
[04:53] <jordi> are you a gnomebaker maintainer?
[04:53] <lbm> well, i'm the translation coordinator for gnomebaker
[04:53] <lbm> i'm a maintainer yes
[04:53] <lbm> but i need to understand this system
[04:54] <jordi> just ask
[04:55] <lbm> it's possible for every user to translate the template in ubuntu packages, right?
[04:55] <jordi> no, only people in the "Ubuntu translators" translator group
[04:56] <jordi> anyone can translate the template in thep roduct, though
[04:56] <jordi> https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker
[04:58] <lbm> jordi: okay, are these translations backported to the packages from time to time?
[04:59] <lbm> and how do people get in the "Ubuntu translators" group?
[05:01] <lbm> nevermind about the last question, i didn't realise all the different i18n groups was linked to "Ubuntu translators"
[05:11] <daf> sivang: are you around?
[05:19] <jordi> lbm: we're working on the "backported" thing. For now, it's responsability of the translators to move them from one branch to the other, but we have a plan to be able to say "put all my translations I'm doing for gnomebaker MAIN in all ubuntu releases"
[05:19] <jordi> etc
[05:24] <SteveA> stub: hello
[05:28] <lbm> jordi: great! so users shouldn't really translate missing strings in the ubuntu package templates?
[05:28] <lbm> yet it is
[05:32] <lbm> since all work essentially aren't used
[05:32] <jordi> lbm: they are used in language packs for ubuntu
[05:32] <jordi> lbm: what they should do, is export their work and import it in the distro
[05:32] <jordi> it'll be a lot easier when we have this feature in place
[05:33] <lbm> okay
[05:34] <lbm> jordi: i see one branch, MAIN, which is fint
[05:35] <lbm> but also two "versions"
[05:35] <lbm> why?
[05:44] <jordi> let me see
[05:45] <jordi> ok
[05:45] <jordi> so you have a branch
[05:45] <jordi> which is your CVS/SVN trunk version
[05:45] <jordi> and, someone has registered two releases coming from that branch.
[05:46] <jordi> so when 0.5.4 releases, you can register that release too
[05:46] <lbm> they shouldn't be there
[05:47] <lbm> and what is the difference between release series and branch? which type is "MAIN" in the product?
[05:48] <lbm> i can't see why other people should be able to create these releases
[05:55] <jordi> hmm.
[05:55] <jordi> They shouldn't be able
[05:56] <jordi> if they are able to, it's a very grave bug
[05:56] <lbm> the former maintainer did one of them, but the other person i don't know
[05:57] <lbm> shouldn't i as the maintainer be able to edit all aspects of the product, such as removing those releases?
[06:03] <jordi> yes, these are current limitations in the system. It's improving, but it takes time.
[06:04] <lbm> okay, could you please delete those releases
[06:04] <lbm> what is the difference between release series and branch? which type is "MAIN" in the product?
[06:12] <LarstiQ> bazaar.launchpad.net isn't reachable for me, should it be?
[06:27] <jordi> lbm: MAIN is a series
[06:27] <jordi> a Branch is a "bazaar branch", nothing to do with the series
[06:29] <lbm> okay, and branch can also contain translations?
[06:32] <lbm> i don't get the idea, really
[06:34] <jordi> no
[06:34] <jordi> forget about branches, you should have in mind there are templates for a given series
[06:34] <jordi> and templates for ubuntu releases
[06:34] <lbm> okay :)
[06:35] <jordi> branches is to register a bazaar branch with gnomebaker code, which isn't your case now.
[06:35] <jordi> aha
[06:35] <lbm> oh, i see
[06:35] <jordi> maybe this helps a little bit, because it explains the difference between the two
[06:36] <jordi> http://wiki.launchpad.canonical.com/RosettaNewImportPolicy
[06:37] <lbm> thanks ;)
[06:38] <jordi> np!
[06:38] <jordi> I know we're missing docs. I'm working on it, but you imagine it's qutie a huge task
[06:38] <jordi> for now, just ask me! :)
[06:39] <jordi> SteveA: I wonder if you have access to removing product releases from a rpoduct page
[06:39] <jordi> if so, can you get rid of those two xqf releases?
[06:40] <lbm> jordi: the two gnomebaker releases in MAIN series also, please
[06:43] <jordi> SteveA: doh
[06:43] <jordi> I said xqf, I meant gnomebaker!
[06:43] <jordi> lbm: oops!
[06:44] <lbm> :)
[06:44] <SteveA> jordi: i can't do that.  only stu can remove things, in general.
[06:44] <jordi> ok.
[06:44] <jordi> I'll mail the list.
[06:46] <jordi> done
[06:46] <jordi> lbm: I expect this to be done in the next few hours.
[06:47] <lbm> jordi: thanks alot
[06:47] <jordi> np!
[06:47] <lbm> jordi: are templates (pot) and translations (po) sync'ed from, in this case, cvs yet?
[06:48] <lbm> i see launchpad have the details already: https://launchpad.net/products/gnomebaker/+series/main
[06:52] <jordi> not yet
[06:52] <jordi> tis "syncing" thing is that it's syncing CVS with the bazaar branch launchpad creates for it.
[06:53] <jordi> lbm: for now, you need to manually upload new templates.
[06:54] <lbm> jordi: okay, i'm close to get a basic understanding :)
[06:54] <jordi> keep the questions coming ;)
[06:55] <lbm> jordi: maybe you guys should write a weekly update and throw it at launchpad-users
[06:58] <dilys> Merge to devel/launchpad: [r=jamesh]  implement InitialBugConctacts and fix a nasty login() bug (r2932: Brad Bollenbach)
[07:01] <marc``> I come to register, but email of confirm don't come yet...
[07:02] <SteveA> hi marc``
[07:03] <SteveA> how long have you been waiting?
[07:04] <marc``> 10min
[07:05] <marc``> I hope it's automatic... so normally I would have it :)
[07:05] <lbm> jordi: let's say i edit the danish translation of MAIN locally and another guy do it through rosetta, he saves and i upload my changes, how is this merged?
[07:05] <SteveA> marc``: well, it should have come to you
[07:06] <jordi> lbm: will depend on the kind of upload you do.
[07:06] <SteveA> marc``: can you /msg me the email address you used?
[07:06] <SteveA> i'll try sending you a test message from the server
[07:06] <jordi> if you do a "published upload", the guy will have preference
[07:06] <jordi> if not, you'll have precedence
[07:07] <SteveA> actually, marc``, that might not work
[07:07] <marc``> SteveA: thanks, I will wait yet...
[07:07] <lbm> jordi: https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker/+upload says nothing about published or not
[07:08] <SteveA> unless you are registered with this irc server
[07:08] <jordi> lbm: a general upload (for a pot + all languages) is always considered a published upload
[07:08] <SteveA> marc``: if you still have problems later, mail me: steve @ canonical.com
[07:09] <jordi> lbm: compare that to this
[07:09] <SteveA> be sure to tell me what email address you use to sign up with
[07:09] <jordi> https://launchpad.net/products/gnomebaker/+series/main/+pots/gnomebaker/ca/+upload
[07:11] <jordi> lbm: see?
[07:14] <lbm> jordi: oh, i see, thanks
[07:24] <carlos> lbm, I'm back. It took me much more time than I expected...
[07:24] <carlos> lbm, did jordi solved all your questions?
[07:25] <jordi> carlos: for now :)
[07:27] <carlos> jordi, cool, thanks!
[07:28] <lbm> :)
[07:33] <jordi> I'm out of office now
[07:47] <sivang> daf: now I am , what's up?
[08:06] <SteveA> bradb: https://wiki.launchpad.canonical.com/BugzillaImportProcess
[08:08] <bradb> SteveA: The status of InitialBugContacts (as per the "To do" item) is that it's landed and ready to go.
[08:09] <SteveA> yep
[08:09] <SteveA> i added that to the notes
[08:09] <SteveA> would you update the notes when the status changes land?
[08:10] <bradb> Sure.
[08:10] <bradb> Do you mind if I remove the todo item about checking the IBC status?
[08:11] <SteveA> bradb: does the import script take account of IBC?
[08:12] <bradb> I specifically added PackageBugContacts beforehand so that jamesh could work with it, so it should. jamesh would have to confirm the default assignee => package bug contact conversion.
[08:12] <SteveA> so, you can change it to specifically confirm this
[08:12] <bradb> ok
[08:14] <bradb> updated
[08:35] <lbm> carlos: around?
[08:35] <carlos> lbm, yes
[08:36] <lbm> carlos: about translation export
[08:36] <carlos> lbm, yes?
[08:37] <lbm> carlos: rosetta doesn't retain the original comments in the top, which is quite bad
[08:37] <lbm> carlos: many groups have word conventions and comments there
[08:38] <carlos> lbm, hmmm, we store them
[08:38] <carlos> lbm, if you don't get them, it's a bug
[08:39] <lbm> carlos: one second, maybe it's my fault
[08:39] <carlos> ok
[08:40] <lbm> carlos: but there should be a way to edit comments in the top and individual string comments
[08:41] <carlos> lbm, yeah, that's a planned feature
[08:41] <lbm> carlos: great, do you have this list on the wiki?
[08:41] <carlos> the list of features?
[08:41] <carlos> well, we have a RosettaWishList
[08:42] <lbm> planned features, yes
[08:42] <carlos> but I think it's a bit outdated
[08:42] <lbm> okay, let me take a look
[08:42] <carlos> wiki.ubuntu.com/RosettaWishList
[08:42] <carlos> lbm, we have also some things at malone
[08:42] <lbm> okay
[08:42] <carlos> but the place where you can see our priorities is at https://launchpad.net/products/rosetta/+specs
[08:43] <carlos> lbm, the ones Approved with Essential or High priority are the features we are going to implement really soon
[08:43] <lbm> great, thanks
[08:44] <SteveA> carlos: did you see the notes on fixing some of the timeout problems in one of the bugs daf and i worked on today?
[08:44] <SteveA> on the suggested / wikimode translations
[08:44] <bradb> Where is the latest and greatest LP tree? I need access to the bleeding edge to resolve conflicts/failing tests in the status changes branch.
[08:44] <bradb> I though it would be in /home/warthogs/archives/rocketfuel/launchpad/devel, but my patch is not there.
[08:45] <SteveA> bradb: maybe jblack can help with that, and add the answer to the bzr-for-launchpad docs
[08:45] <SteveA> bradb: remember about pqm being elsewhere
[08:45] <SteveA> it may take a few minutes for them to sync up
[08:45] <bradb> Yep.
[08:45] <SteveA> but i do not know the details
[08:45] <bradb> I've been waiting for almost two hours, that's why I ask.
[08:46] <SteveA> in a few hours more, lifeless will be around for a definitive answer
[08:46] <carlos> SteveA, yes, I saw them
[08:46] <SteveA> it would be good to get these things documented, though
[08:46] <bradb> indeed
[08:46] <carlos> SteveA, and it's a good start to improve that timeout problem, thanks
[08:46] <SteveA> carlos: i think fixing that would make a huge difference to people using rosetta
[08:47] <carlos> SteveA, ok, I will implement them now, it's one of the most reported bugs we have atm...
[08:47] <SteveA> that's great carlos
[09:02] <lbm> carlos: my fault, comments was exported as well, sorry
[09:03] <carlos> lbm, no worries
[09:07] <lucasvo> is launchpad offering to host a branch of bzr? We need a place to host Edubuntu cookbook
[09:21] <carlos> lucasvo, launchpad mirrors bzr branches, yes (or at least will do it soon) but you still need a public place from where launchpad fetchs it
[09:22] <lucasvo> carlos: ah, ok
[09:23] <salgado> cprov, I added two more questions (the ones at the bottom) to https://wiki.launchpad.canonical.com/MirrorManagement. would you check to see if you know the answer?
[09:24] <lucasvo> carlos: so it is only a mirror, not meant as a place where all the developers merge togehter?
[09:24] <cprov> salgado: sure
[09:26] <carlos> lucasvo, yes, at least now. Perhaps in the near future it would host archives... Anyway, is better if you talk with lifeless, ddaa or jblack about it
[09:26] <carlos> lucasvo, I don't know all the details
[09:26] <lucasvo> ok
[09:50] <highvoltage> hi. any launchpad admins around?
[10:19] <sivang> carlos: I think supermirror is the place where archives will be hosted, and launchpad will just watch them?
[10:21] <carlos> sivang, supermirror is part of launchpad at least I think it will be
[10:21] <carlos> highvoltage, hi, what do you need?
[10:22] <highvoltage> carlos: i need to change the e-mail address my @ubuntu.com forwards to.
[10:22] <sivang> carlos: ah :)
[10:23] <snotling> hello, there's a package in dapper which is not present in malone -- a package for which i'd like to file a 'bug', an update wish that is
[10:24] <carlos> highvoltage, hmmm, I'm not sure I'm able to do that....
[10:24] <highvoltage> carlos: ok, thanks. i'll hang around a bit more.
[10:24] <carlos> highvoltage, what's your current address?
[10:25] <highvoltage> it currently forwards to<EMAIL_ADDRESS>(from<EMAIL_ADDRESS>[10:26] <carlos> highvoltage, I think it does not depends on launchpad (at least now)
[10:26] <carlos> highvoltage, ask Znarl or elmo
[10:26] <highvoltage> ah, ok.
[10:26] <jordi> carlos: hey I saw the distro info on gnomebaker today
[10:26] <carlos> highvoltage, they are our sysadmin
[10:26] <jordi> that's very cool
[10:26] <highvoltage> carlos: I'll contact them, thanks.
[10:26] <carlos> highvoltage, you are welcome
[10:27] <carlos> jordi, ?
[10:27] <jordi> carlos: I hadn't seen that at all yet
[10:27] <jordi> if you go to gnomebaker/breezy, you have the distro info
[10:28] <carlos> jordi, https://launchpad.net/products/gnomebaker/breezy ?
[10:28] <carlos> it's a 404 page
[10:30] <jordi> carlos: no, in the distros/uubntu tree
[10:31] <carlos> jordi, oh! you mean the distro info
[10:31] <carlos> jordi, gina run ;-)
[10:32] <jordi> yeah
[10:45] <bradb> lifeless: ping
[10:50] <bradb> lifeless: Ah, n/m, I see on launchpad@ that you're working on fixing the chinstrap code synching problem.
[11:03] <mdke> spiv, around?
[11:08] <kjcole> ping any launchpad wizard. ;-)
[11:12] <SteveA> what's up kjcole ?
[11:13] <kjcole> Hi,  I'm looking at launchpad.net and it appears the only way to get a bzr branch there is to import it from something other than bzr. True?
[11:14] <SteveA> kind of
[11:15] <SteveA> this will be changing during next month
[11:15] <SteveA> and you'll be able to sftp push a branch to the supermirror
[11:15] <SteveA> and have it appear in launchpad
[11:16] <lifeless> morning
[11:16] <SteveA> morning lifeless
[11:17] <lifeless> SteveA: kjcole: you can have launchpad.net copy your existing bzr branches today.
[11:18] <SteveA> how does that work?
[11:18] <lifeless> SteveA: login to launchpad, visit your home page, click 'code', click 'add branch'
[11:19] <lifeless> bradb: pong
[11:19] <SteveA> lifeless: how does that copy my existing bzr branch?
[11:20] <lifeless> SteveA: a cron job will copy the branch from the location you give to http://bazaar.launchpad.net/~YOU/product/branchname
[11:22] <SteveA> wow.  advanced tech
[11:22] <bradb> lifeless: Are you still working on the problem of synching the latest Launchpad code onto chinstrap?
[11:23] <lifeless> SteveA: better believe it
[11:23] <kjcole> lifeless, so if I wait, my bzr branch will get picked up?  (I did the "add branch" several weeks ago.)
[11:24] <lifeless> kjcole: yes.
[11:24] <lifeless> kjcole: the statistics wont operate until early jan
[11:25] <lifeless> kjcole: http://bazaar.launchpad.net/~kjcole/edubunto.cookbook/wip is your branch
[11:25] <lifeless> kjcole: thats where it will be published once picked up
[11:25] <kjcole> lifeless, oh goodie. ;-)
[11:25] <lifeless> bradb: I dont know what you are talking about
[11:26] <bradb> lifeless: The problem BjornT reported to launchpad@: not being able to synch up with the latest revision.
[11:30] <lifeless> bradb: there was something 3 odd days ago now
[11:30] <lifeless> bradb: which was fixed
[11:30] <lifeless> bradb: are you talking about something more recent ?
[11:31] <lifeless> bradb: w.r.t. the story patch, I'm offering to do the tests for it. If it passed the review team without tests before, well - you can of course land it, its not my call to stop it, but I'd much rather that it land with tests.
[11:32] <lifeless> *MUCH*
[11:32] <bradb> lifeless: I thought it was the same problem. The most recent revision is not available at chinstrap:/home/warthogs/archives/rocketfuel/launchpad/devel.
[11:33] <bradb> lifeless: I didn't merge --story with the InitialBugContacts merge. I reversed the patch to avoid blockage.
[11:34] <bradb> lifeless: i.e. this rev is not available in anywhere I'm used to looking: http://lists.canonical.com/mailman/private/arch-commits/2005-December/005132.html
[11:34] <bradb> Not having access to this patch is blocking merging the status changes.
[11:35] <lifeless> bradb: its being pushed up at the moment
[11:35] <lifeless> that takes upwards of 40 minutes or more
[11:35] <bradb> ok. presumably this problem is being fixed then?
[11:35] <lifeless> bradb: there is no specific problem here
[11:36] <lifeless> bradb: just the general performance issues that are in the pipeline
[11:36] <lifeless> bradb: there *was* a problem earlier in the week.
[11:37] <bradb> lifeless: I'm not sure what you mean. I've been waiting to get access to this code for six hours. How is that not a specific problem?
[11:37] <lifeless> bradb: thats how long it can take right now
[11:37] <bradb> oh
[11:37] <bradb> An email to launchpad@ might have helped avoid some head-banging. ;)
[11:38] <lifeless> but thats an extreme case
[11:38] <lifeless> its from you right
[11:38] <lifeless> why dont you just merge sideways ?
[11:38] <bradb> I wasn't sure if I could trust that. If I can, I will.
[11:39] <lifeless> its been merged (the email is only sent out after pqm passes it by policy).
[11:39] <lifeless> it then gets pushed locally on balleny, which is a almost-impossible-to-fail operation
[11:40] <lifeless> it then gets pushed to chinstrap, which was failing because of a stale sftp lock, probably because someone killed pqm.
[11:40] <lifeless> if the push to chinstrap fails, the local push to balleny is uncommitted.
[11:40] <lifeless> so you cant -trust- it. But it *has* passed the pqm test run successfully.
[11:40] <lifeless> I hope that helps clarify it
[11:42] <bradb> Clearer. Hopefully this won't meet with the same chinstrap push failure next time. I just want to land. ;)
[11:45] <lifeless> if it meets the same failure as earlier this week, pqm will now email you to tell you
[11:47] <bradb> ok. btw, I'm not sure why there's another InitialBugContacts merge request from me in pqm's queue. It seems to have been there for a while now.
[11:47] <lifeless> thats this one
[11:48] <lifeless> until it finishes the mirror to chinstrap its still the active job
[11:48] <lifeless> once that finishes you will get your 'its all ok' confirmation from pqm.
[11:48] <bradb> ah
[12:03] <kjcole> lifeless, thanks for the help.  Between you and ogra, I'm slowly digesting it all... I think. ;-)  I'm going to run now and ponder the great mysteries of bzr/launchpad, etc.


[07:39] <alphacrypt> hey, trying <IP_ADDRESS> kubuntu and get a crash with message like that https://bbs.archlinux.org/viewtopic.php?pid=1340786#p1340786
[08:56] <apw> alphacrypt, does it cause issues or just informational
[08:57] <alphacrypt> it get stucks at boot
[09:28] <cking> smb, bug 1292674
[09:28] <ubot2> Launchpad bug 1292674 in virt-manager (Ubuntu) "virt-manager.py is being exec'd every second when running virt-manager" [Undecided,New] https://launchpad.net/bugs/1292674
[09:28] <smb> cking, looking
[10:15] <alphacrypt> apw ideas?
[11:15] <jarkko> -
[13:33] <tseliot> apw: please make sure that LP: #1292563 is fixed, it's a nasty issue
[13:33] <ubot2> Launchpad bug 1292563 in linux (Ubuntu Saucy) "nvidia driver fails to initialize on Haswell without upstream kernel patch" [High,Triaged] https://launchpad.net/bugs/1292563
[14:35] <apw> tseliot, ack
[14:36] <tseliot> thanks
[14:44] <apw> tseliot, that is already fixed in trusty at least
[14:45] <tseliot> apw: yep, but oem projects currently based on 12.04.4 will fail
[14:53] <apw> tseliot, have you tested that this fix actually works as claimed ?  if so you could submit it directly
[14:55] <tseliot> apw: not really, I don't have access to a haswell system with optimus. I do trust Aaron from NVIDIA though ;)
[14:55] <tseliot> (he developed most of the code to use optimus)
[14:58] <apw> yeah, hmmm, well thats not going to get it through SRU, i'll shove some test bits his way
[14:59] <tseliot> apw: sounds good to me, thanks
[20:03] <miseria> "estoy solo en mi balcon, el viento acaricia mi rostro pero se lleva mi alma a bailar con las hojas secas que pasan y pasan" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[22:02] <trippeh> In case you guys is going to work / is working on 3.14, it breaks pam in lxc. have to boot with audit=0.
[22:03] <trippeh> https://www.redhat.com/archives/linux-audit/2014-February/msg00087.html
[22:35] <apw> trippeh, thanks for the warning, i suspect we will skip 3.14 alltogether by the time the archive opens for U
[22:35] <apw> so we will likely be ok
[22:38] <k0fee> what channel do i go to for help with ubuntu 11 since it's eol
[22:38] <k0fee> need to find a working repo
[22:38] <k0fee> thanx
[22:40] <infinity> k0fee: #ubuntu
[22:41] <apw> k0fee, 11? what release was that
[22:41] <infinity> apw: I assume he means either 11.04 or 11.10
[22:41] <apw> is that like natty?
[22:41] <infinity> k0fee: Anyhow, old releases live at http://old-releases.ubuntu.com/ubuntu/ ... Any support beyond that, you might find from #ubuntu, or you might be on your own, but this is definitely not the place to ask. :P
[22:42] <k0fee> yes
[22:42] <k0fee> i've been googling for over a day on this, just love natty, know it's old but love "her" ;)
[22:42] <k0fee> want to put couple regular apps on it from the repo
[22:42] <k0fee> ok i'll leave have a good one
[22:43] <jtn> rtg/whoever: re the Wacom Intuos driver update you pushed for me a couple of days ago with today's xubuntu daily cdimage (containing kernel 3.13.0-18.38), and confirm that it now just works out of the box. Thanks again.
[22:44] <jtn> Er, that's garbled. What I mean is, I tried today's xubuntu daily and it worked.
[23:26] <apw> jtn, what was the bug number, it is best to feed that back in the bug as well
[23:29] <jtn> apw: I'm not aware that there was ever a bug. I just came on here and asked. I believe that resulted in a set of cherry-picks such as this one: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=637c04c4e1c8a9d1f1dce9c61bcf58ee3dc73297