[04:08] <ianm_> I have a project with auto-pot-file-finding setup.  if I commit with the pot file gone (from root directory) and now in locate/templates and with many more strings for translation, will everything work OK?
[04:09] <ianm_> (I downloaded a package of all .mo files from launchpad into locale/ and that included the .pot, and then I overwrote it with a newly generated one, and did not do 'bzr mv'.)
[08:34] <sagaci> looks like it's down
[08:36] <wgrant> sagaci: It's back now. http://blog.launchpad.net/notifications/fast-down-time
[08:36] <sagaci> yep
[09:15] <mrevell> Morning
[10:05] <danhg> huwshimi
[13:35] <dpm> hi launchpad folks. Could someone tell me if a translation template (e.g. po/mytemplate.pot) will be imported by automatic imports if the .pot file is a symlink?
[14:53] <dpm> hey, anyone there who could help me with the question? "will a translation template (e.g. po/mytemplate.pot) be imported by automatic imports if the .pot file is a symlink?" thanks!
[15:33] <Gwaihir> any launchpad dev out there? I have a "simple" question: is Launchpad sending notifications about team expiration? More than one person reported that they have never received a notification email... this is happening also for Ubuntu Membership renewals...
[15:35] <nigelb> Is this very recent?
[15:35] <nigelb> I was complaining about too much email about expiration like 2 to 3 weeks ago :)
[15:36] <Gwaihir> nigelb, kind of... they told me yesterday, but the expiration was like one month ago
[15:36] <nigelb> There was a bug a while back. I don't know if that's this.
[15:36] <Gwaihir> also, other people never received a notification around the beginning of november
[15:37] <nigelb> Let me quickly check, which week I had the email.
[15:37] <Gwaihir> thx nigelb
[15:37] <nigelb> Hrm, I had expiration emails in the first week of Nov.
[15:38] <nigelb> Nov 7th was the last I had the email.
[15:42] <Gwaihir> the person who didn't get the notification was set to expire on the 10th November
[15:42] <Gwaihir> the other one was around the 9 of October...
[15:42] <nigelb> Hrm, I don't know who's help contact for today.
[15:51] <Corey> This may be better asked elsewhere, but: I'm digging into repackaging lighttpd for a one line patch that's been outstanding since 2005.  Rather than re-inventing the wheel, is there a straightforward way to grab the preexisting dsc files so I can tweak accordingly?  Not too interested in redoing it all just because I know best. ;-)
[15:55] <tumbleweed> Corey: yes, it is better asked elsewhere, e.g. #ubuntu-packaging. But you want pull-lp-source in ubuntu-dev-tools
[15:58] <Corey> tumbleweed: Thanks!
[15:58] <mgariepy> hello, I have an account on launchpad and i cant find a way to change my password... on my detail page it doesn't show anything about password change
[15:58] <nigelb> mgariepy: login.launchpad.net should get you to such a page.
[15:59] <nigelb> launchpad doesn't store your credentials.
[15:59] <nigelb> login.launchpad.net is the Single-Sign On which is under the same domain, but isn't actually part of launchpad.
[16:00] <mgariepy> would it be possible to add a link in detail page of my account ?
[16:00] <mgariepy> or any account..
[16:02] <nigelb> Like I said, its not really launchpad which does this.
[16:02] <nigelb> So, it doesn't belong in launchpad.
[16:02] <mgariepy> ok thanks for you time
[16:04] <xaprb> I want to add a new status to my bug tracker, so I can close bugs as CantReproduce. I can't find this in Launchpad or through Google. Can someone point me to the right place?
[16:04] <xaprb> s/to my bug tracker/to my project's bug tracker/
[16:38] <Chipaca> hi all. I'd like to create a sub-team, but can't seem to find what to click :)
[16:41] <Corey> I've added (successfully!) a package to my PPA, but now when I try to add the PPA, I'm getting Error: can't find signing_key_fingerprint at https://launchpad.net/api/1.0/~kb1jwq/+archive/ppa.  The notes say that generating the key after the first package upload can take several hours, but how do I verify that that's the actual issue, and not "I screwed something up?"
[16:42] <tumbleweed> that's almost certainly the issue
[16:44] <Corey> tumbleweed: How will I know when the key has been generated?  Is there a flag that gets set in Launchpad somewhere?
[16:45] <tumbleweed> Corey: under "Technical details about this PPA" you'll se a "Signing key" listed
[16:46] <Corey> Ahhh.
[16:46] <Corey> That's blank.
[16:46] <Corey> That'd do it. :-)
[16:48] <Corey> Ah, now the key is generated, but hasn't made its way to the keyserver yet.  So many moving parts!
[17:09] <thopiekar> Hi
[17:10] <thopiekar> Could you please remove "maliit-plugins - 0.80.8~stable~r1526~pkg10~oneiric1" fully from ppa:maliit-team/ppa, so a package with the version 0.80.8~releasepkg1526+10~oneiric1  can be uploaded? thanks
[17:17] <tumbleweed> thopiekar: it doesn't work like that
[17:18] <thopiekar> I know removing packages will leave something on the PPA and a lower version won't be uploadable like before.. tumbleweed, how can it be done?
[17:18] <tumbleweed> thopiekar: why the change in version format?, looks like the same revision
[17:19] <thopiekar> sure but changes on the source won't be uploaded by the recipe now.. while s is higher than r
[17:20] <tumbleweed> thopiekar: then why di dyou change the recipe?
[17:21] <danhg> mrevell
[17:22] <tumbleweed> thopiekar: even if you could make the ppa accept a lower version, which you can't, nobody would upgrade any more, because apt won't upgrade to a lower version (that's why the PPA won't let you upload a lower version)
[17:22] <thopiekar> well our coding team decided to call the packages an other way.. I were thinking about stable, but the software isn't really stable still the latest release..
[17:22] <thopiekar> sure..
[17:22] <tumbleweed> how about unstable, then, u comes after s :)
[17:23] <thopiekar> thats why I wish this package would be remove again..
[17:23] <thopiekar> tumbleweed: unstable is placed in a daily ppa
[17:23] <tumbleweed> and 0.80.8 > 0.80.8~unstble123+45~whatever
[17:23] <thopiekar> there are the nightly builds
[17:24] <thopiekar> is a + or - higher than ~?
[17:24] <thopiekar> or better: what is higher than ~?
[17:24] <tumbleweed> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[17:25] <tumbleweed> ~ is special
[17:26] <thopiekar> would be 0.80.8.0~ higher than 0.80.8~?
[17:27] <tumbleweed> $ dpkg --compare-versions '0.80.8.0~' '>>' '0.80.8~' && echo Yes || echo No
[17:28] <thopiekar> thanks!
[17:28] <thopiekar> btw. whats up with the builders?
[17:28] <tumbleweed> https://launchpad.net/builders
[18:15] <Corey> Who do I bribe and what does it cost to boost the priority on an i386 build for my personal PPA? :-)
[18:32] <cjohnston> Is it possible to have an alias for a team as it is for a project?
[18:34] <lifeless> no
[18:34] <cjohnston> ty lifeless
[18:49] <dobey> you guys know what would be awesome?
[18:49] <dobey> private attachments on public bugs
[18:50] <EvilResistance> but if they're public bugs the attachments should be public as well
[18:50] <EvilResistance> hence the name "PUBLIC bugs"
[18:51] <dobey> not necessarily
[18:51] <EvilResistance> well then i ask you
[18:51] <EvilResistance> what would be the usefulness of this feature?
[18:51] <EvilResistance> because the public sometimes submits bug fixes
[18:51] <EvilResistance> for projects they may not even be a member of
[18:52] <EvilResistance> (case in point: me and a few projects)
[18:52] <dobey> for users to attach logs, that only the project owners can see, but which regular people cannot
[18:52] <dobey> i didn't say all attachments should be private
[18:52] <EvilResistance> therefore you are invalidating the entire concept of public bugs
[18:52] <EvilResistance> when a bug is posted publicly
[18:53] <EvilResistance> the intent is so that the public can assit with it
[18:53] <EvilResistance> perhaps even fix it
[18:53] <dobey> sigh
[18:53] <EvilResistance> by posting logs detailing an issue...
[18:53] <EvilResistance> but hiding that from the public
[18:53] <EvilResistance> you therefore prevent the public collaboration which Ubuntu and other projects are so familiar with
[18:53] <dobey> well if you want to post your own potentially private data in public view, then go ahead.
[18:54] <dobey> also, who are you, since your /whois provides no useful information at all
[18:55] <EvilResistance> i'm a member of the ubuntu community ;P
[18:55] <EvilResistance> you can ascertain that by the end part of the host name
[18:55] <EvilResistance> ubuntu.resistance
[18:55] <EvilResistance> where resistance is my nickname
[18:55] <EvilResistance> and ubuntu is the project
[18:55] <EvilResistance> if you'd like, feel free to scan my launchpad: https://launchpad.net/~trekcaptainusa-tw
[18:56] <cjohnston> whats the difference between having a public bug with private attachements vs a private bug with private attachments?
[18:56] <EvilResistance> ^
[18:56] <EvilResistance> that
[18:57] <cjohnston> either way you are as you say 'preventing the public collaboration'
[18:57] <dobey> cjohnston: because people who aren't subscribed to private bugs cannot see anything about the bug at all
[18:58] <dobey> and the only reason it's private, is because someone has an attachment of logs or something, with possibly private data
[18:58] <cjohnston> dobey: im trying to support your opinion :-P
[18:58]  * EvilResistance can interpret cjohnston's original question as working in favor of EvilResistance's opinion
[18:58] <EvilResistance> cjohnston:  your question was worded like an expert attorney :P
[18:58] <dobey> cjohnston: your comments are worded against it, rather :)
[18:58] <EvilResistance> depending on the answer of course
[18:58] <EvilResistance> :P
[18:58] <cjohnston> EvilResistance: yes. i do agree.. so basically.. why not
[18:59] <cjohnston> if i can see the bug, and the description, and i say, oh wait.. i have that problem too...
[18:59] <cjohnston> but i just cant see the OPs logs
[18:59] <EvilResistance> but consider
[18:59] <EvilResistance> someone not having this problem
[18:59] <EvilResistance> but is willing to attempt to fix it
[18:59] <EvilResistance> or rather
[18:59] <dobey> probably doesn't care to fix it
[19:00] <EvilResistance> someone having this problem
[19:00] <EvilResistance> but is willing to fix it
[19:00] <dobey> because you can't fix soemthing you can't see yourself, unless it's a very obvious thing
[19:00] <dobey> which it usually is not
[19:00] <EvilResistance> without the logs we cant fix it
[19:00] <EvilResistance> that's the issue
[19:00] <cjohnston> but that is no different than someone not having this problem and not being able to see the bug anyway
[19:00] <EvilResistance> ^
[19:00] <EvilResistance> but the issue is ***why*** people provide logs of issues
[19:00] <cjohnston> EvilResistance: not necesarally
[19:00] <EvilResistance> they provide it so people can ***find*** whats wrong and fix it
[19:01] <cjohnston> many times, yes.. not all times relevant tho
[19:01] <EvilResistance> consider the Ubuntu packages.  Not every package is actively checked
[19:01] <dobey> EvilResistance: please stop arguing just for the sake of disagreeing
[19:01] <EvilResistance> dobey:  i dont see a launchpad staff nick on you, nor do i see you in the ops list, nor do i see freenode staff cloaks on you
[19:01] <EvilResistance> so you're not in an opinion to stop me from voicing my opinions
[19:01] <EvilResistance> grah
[19:01] <EvilResistance> you're not in a position, even
[19:02] <lifeless> dobey: I think it would be very easy for folk to copy and paste from a private attachment into the bug body thus disclosing private info
[19:02] <lifeless> dobey: so it would be a pretty effective foot-gun situation to setup
[19:04] <dobey> lifeless: it's already easy to do that; but if only the reporter, and the bug team (?) can see the attachment, then that doesn't really seem like an issue does it?
[19:04] <maxb> Whilst occasionally there's a genuine need to communicate debug info privately, most times logs should be fine to make available publically, such that any community member can assist
[19:05] <lifeless> EvilResistance: hi; dobey's question was a pretty good one - we support private bugs already, precisely so that private content can be analysed without public disclosure of personally identifying information.
[19:05] <EvilResistance> lifeless:  his question isnt about private bugs
[19:05] <EvilResistance> its about allowing attachments to be private on public bugs
[19:05] <dobey> maxb: but that's not true for certain projects
[19:05] <lifeless> EvilResistance: there was no need to esclate your response so much
[19:05] <EvilResistance> lifeless:  which therefore defeats the purpose of public bugs
[19:06] <EvilResistance> lifeless:  sorry, kind of part of my nature... its gotten me in some trouble with freenode staff in the past
[19:06] <lifeless> EvilResistance: actually, his question is about allowing currently private bugs to be public by keeping just some attachments private
[19:06] <EvilResistance> lifeless:  i interpret the initial statement differently.
[19:06] <EvilResistance> <dobey> you guys know what would be awesome?
[19:06] <EvilResistance> <dobey> private attachments on public bugs
[19:06] <lifeless> EvilResistance: he wants to *increase* publicness, not *decrease* it.
[19:06] <EvilResistance> ^  that is the opposite of what you just stated.
[19:06] <EvilResistance> save for that last line
[19:06] <lifeless> EvilResistance: with the greatest respect, its not.
[19:07] <tumbleweed> EvilResistance: we currently have lots of private bugs, this would let us have less of them
[19:07] <lifeless> EvilResistance: his question asks about a situation that doesn't exist today, it makes no declaration of intent or path-to-that-situation
[19:08] <lifeless> EvilResistance: assigning motivation, and speculating about cause and effect requires asking questions, not stating conclusions
[19:08] <lifeless> maxb: indeed, and I don't think dobey will disagree with that.
[19:09] <lifeless> maxb: however, the UK DPA and similar legislation elsewhere in the world is pretty clear about the obligation to protect personal (and personally identifying) information.
[19:10] <lifeless> dobey: I believe it has been considered in the past and concluded to be an unacceptably high risk; tech wise we could quite easily do it.
[19:11] <lifeless> dobey: I think we would want some rather rigorous user testing around such a feature, because the consequences can be pretty bad
[19:11] <dobey> lifeless: i wonder if perhaps with some of the refactoring that has been happening, or will happen, in LP, if it's less of a risk now?
[19:11] <dobey> lifeless: agreed
[19:12] <maxb> It feels like the sort of thing that would be a UI nightmare to ensure first-time reporters used it right
[19:12] <lifeless> dobey: I don't think we'd have an issue in making it happen in LP; the issue is in whether users make mistakes using it :)
[19:12] <lifeless> maxb: yes, exactly.
[19:12] <dobey> lifeless: hence suggestion of only reporter and bug driver/security team/whatever for the project, being able to see private bits
[19:12] <dobey> lifeless: in which case, it wouldn't really be any more of a risk than the current situation, would it?
[19:12] <maxb> Also would probably want to be opt-in on a project basis so that people only use it where there is a sufficient population of active bug triagers
[19:13] <lifeless> dobey: sure it would - how many first time bug reporters would understand it such that when someone asks 'can you attach your dmidecode info' they don't copy and paste it into the bug directly?
[19:15] <dobey> lifeless: well, assuming they aren't "file and forget" type of users, i don't know. but we should probably also work on those cases more specifically, such that we don't have people saying "can you run this command and paste it here?" in bugs, but instead such commands do the legwork for the users
[19:16] <dobey> but it's a tough balancing act that, because the same situation exists if the bug isn't already private, anyway :-/
[19:21] <lifeless> dobey: yes, I can see that. However this is why apport defaults to private bugs, no ? Open-after-processing-and-human-review.
[19:21] <maxb> What's the use-case being aimed at here? attachments in an initial apport-filing, or ones created by a user?
[19:22] <dobey> maxb: well, in this specific instance, from the user
[19:22] <dobey> lifeless: does it for all bugs, or only some?
[19:22] <maxb> And what's the content? Something the user understands is private, or something they need to be told might leak info?
[19:23] <lifeless> dobey: crash reports I believe
[19:23] <maxb> In apport's case, it's about protecting core-dumps, mainly, IIUC?
[19:23] <lifeless> anyhow, since this is now cosntructive discussion, I'm going to leave you folk to it :)
[19:24] <dobey> lifeless: right; but ubuntu-bug foo doesn't i guess?
[19:25] <dobey> lifeless: actualy, on +filebug, i don't see any way to make it private by default, other than to say "this is a security problem"
[19:25] <dobey> lifeless: so i'd have to file, then mark it private, then upload attachments
[19:26] <dobey> anyway; just suggesting it would be an awesome feature, because (LP: #PRIVATE) in debian/changelog is no fun :)
[19:28] <maxb> It does seem to make a lot of sense, *if* the restricted material can actually be constrained to the attachments
[19:33] <dobey> maxb: it makes sense to me anyway, and i think it's not really any worse than the current situation; assuming people are never going to make silly mistakes, is a silly mistake. :)
[19:34] <maxb> ooi, what project / particular restricted material were you thinking of?
[19:35] <dobey> maxb: ubuntone stuff. ubuntuone-client logs have filenames/paths in them
[19:36] <dobey> so basically we just let the user decide whether or not that is private to them right now, and just have the bug be private
[19:36] <dobey> also, the new "just 404 on private bugs" behavior is really annoying with irc bots :(
[20:28] <thopiekar> Could you please abort https://code.launchpad.net/~thopiekar/+archive/plasma-dev/+recipebuild/123034 and https://code.launchpad.net/~thopiekar/+archive/plasma-dev/+recipebuild/123033 ?
[22:41] <dupondje> somebody alive in here atm ? :)
[22:41] <wgrant> No.
[22:41] <dupondje> :)
[22:41] <dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349
[22:41] <dupondje> seems to be a bug in Launchpad I guess
[22:41] <dupondje> it doesn't show 'Show all comments' at the bottom
[22:43] <lifeless> dupondje: we load them all always now
[22:43] <wgrant> lifeless: No, something's borked here.
[22:43] <wgrant> Look at the bug.
[22:43] <wgrant> There are at least two large gaps in the comments.
[22:43] <dupondje> they are not all displayed for sure
[22:43] <wgrant> Ah
[22:44] <lifeless> ah 41-65
[22:44] <wgrant> In fact, all the comments are there.
[22:44] <wgrant> They're just loaded in the wrong place.
[22:44] <wgrant> 41-65 are loaded between 14 and 15
[22:44] <lifeless> yay regression
[22:45] <dupondje> and there are more comments also
[22:45] <dupondje> #105 etc exists also :)
[22:45] <dupondje> https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/887349/comments/105
[22:45] <wgrant> s/etc//
[22:45] <lifeless> off by one error
[22:45] <lifeless> two bugs
[22:45] <lifeless> gmb!
[22:46] <dupondje> btw, if you refresh, you get 'Click here to view all 105 comments'
[22:46] <dupondje> but it gets removed with some ajax load
[22:48] <lifeless> yes
[22:48] <lifeless> so comment 0 is the initial description
[22:48] <lifeless> I think there is a fencepost error hiding the last bug, and something else affecting the comment orders
[22:49] <lifeless> the comment numbers are assigned once on receipt, but comments are sorted by date (IIRC), so it could be wacky dates - but the dates on that block of comments look sane
[22:53] <dupondje> seems to be a cool one ;)
[22:55] <lifeless> dupondje: would you do us a favour and file a bug for this?
[22:56] <dupondje> ofc :)
[22:56] <dupondje> https://bugs.launchpad.net/launchpad here I guess?
[23:02] <dupondje> https://bugs.launchpad.net/launchpad/+bug/893375
[23:02] <StevenK> But it's wrong.
[23:02] <StevenK> All comments are shown, they're just mis-ordered
[23:03] <dupondje> Where do you see comment 105 ? :)
[23:05] <StevenK> Neat
[23:06] <dupondje> :)