[00:51]  * yofel hugs jelmer
[00:51] <yofel> thanks for fixing the bzr memory bug!
[04:58] <wildfire> I'm uploading to a ppa (lp.net/~wildfire/+archive/yate) - and the first email I had back indicated an error (I uploaded a binary rather than source) but my subsequent uploads have not resulted in any email back at all. Any hints on how to debug / what to do next?
[04:59] <lifeless> sure
[04:59] <lifeless> there is a wiki page
[04:59] <lifeless> wgrant: wants the ppa upload debug page?
[05:00] <wgrant> https://help.launchpad.net/Packaging/UploadErrors
[05:01] <wgrant> wildfire: The problem is that your OpenPGP key is not registered with your Launchpad account.
[05:35] <persia> For those of you who have listened to me complain about bzr being slow with launchpad, and helped me find ways to make it less incredibly painful, I just want to let you know that I've been using git today against a variety of hosts, and find that I miss bzr's ability to get source in a timely fashion.  Thanks for all the work to make it faster!
[05:41] <lifeless> persia: nice
[05:42] <MostAwesomeDude> Howdy. I'm havin' fun with PPAs.
[05:42] <MostAwesomeDude> I have two source packages with strange licenses. One is PD, and another is MIT/X11. What's the appropriate license to pick for those?
[05:44] <wgrant> MostAwesomeDude: Pikcing for what?
[05:44] <wgrant> debian/copyright?
[05:44] <MostAwesomeDude> Yeah.
[05:45] <MostAwesomeDude> Out of the choices, BSD is pretty close, but I didn't want to "round up" to the next license.
[05:46] <lifeless> MostAwesomeDude: for both, you need to include the licence inline
[05:46] <wgrant> For debian/copyright you can paste the license text there.. you don't have to select one from common-licenses.
[05:46] <MostAwesomeDude> Oh, okay.
[05:46] <lifeless> neither PD nor MIT/X11 are in common-licenses
[05:47] <MostAwesomeDude> Okay. And of course both of those are PPA-friendly, right? I figure that MIT's fine, but I wasn't sure about PD.
[05:51]  * persia murmurs vaguely about the meaning of "public domain" in France
[05:52] <micahg> by the way, where can I report bugs about the wiki on dev.launchpad.net (rendering, not content)
[05:52] <wgrant> As persia says, the global status of PD is, uh, not optimal.
[05:52] <wgrant> But it is generally considered OK for PPAs.
[05:54] <MostAwesomeDude> I'm well-aware that PD is a legally dubious thing in many countries, but I can't really change it.
[05:56] <persia> Indeed.  It's often worth a gentle discussion with upstream.  In most cases, ISC or WTFPL is considered an acceptable dual-licensing arrangement for works released "into the public domain".
[05:56] <persia> But nothing that can be actively done when receiving the work
[05:58] <persia> (although, technically, I suppose one could relicense public domain works if one added "front matter" and then claimed copyright on the compound work, but that gets messy and jurisdiction dependent, and is mostly useless anyway)
[05:58] <MostAwesomeDude> I *am* upstream for this package, these days, but I don't want to relicense until after I've finished some significant restructuring work.
[05:59] <persia> Ah, that's even better :)  If you're thinking PD, I recommend investigating ISC and WTFPL: one of those two is sure to meet your goals.
[05:59] <MostAwesomeDude> I'm familiar with ISC. It would be just fine.
[05:59] <MostAwesomeDude> The other package should stay MIT/X11, since it follows the original spirit. :3
[06:11] <MostAwesomeDude> Woot, success! Thanks, guys. Now to dh_make the other one.
[06:23] <MostAwesomeDude> Hm. What's the correct section for an app written in Python, but that is a server? Should its package name start with "python-"?
[06:23] <poolie> normally python-* is just for libraries
[06:24] <MostAwesomeDude> Ah. Well, the name "bravo" appears unused, so I'll roll with that. It should just go with all the servers, then?
[06:24] <lifeless> if its important by other python code on the system, python-*; if it also has a front end script, consider two binary packages.
[06:29] <wildfire> wgrant: how do you know this?
[06:29] <wildfire> wgrant: https://launchpad.net/~wildfire - has my key listed already
[06:30] <wgrant> wildfire: I checked the upload processor's log file.
[06:30] <wildfire> wgrant: hmm
[06:30] <wgrant> You signed the package with 7BFB2396B1F1454F82EAACEF1C9FDFB760260AF7
[06:31] <wildfire> ok, I'll try again - and ensure I've selected the right key
[06:31] <poolie> hello wildfire
[06:31] <wildfire> poolie: hey martin
[06:31] <wildfire> back in Sydney?
[06:32] <poolie> yes; you?
[06:34] <wildfire> yup, leave on Tuesday
[06:34] <wildfire> have been back for a few weeks actually
[06:37] <poolie> oh, ok
[06:37] <poolie> we could have lunch or something if you have time
[06:37] <wildfire> hmm - what are you up to tomorrow?
[06:37] <wildfire> wgrant: seems to be accepted now - thanks for checking
[06:38] <wgrant> wildfire: Great.
[06:40] <wildfire> poolie: I'm meeting malcolm at the red oak tomorrow
[06:59] <MostAwesomeDude> Woot, success! Thanks, guys.
[07:13] <tjaalton> morning! i've got an issue with the launchpad list email going to the preferred email account though I've set a list to use another account
[08:16] <janimo> what is the "List commented bugs" link showing in a user's LP bug page?
[08:16] <janimo> I'd like to clean up my bugs list to only contain things I am currently interested in, but old open bugs which I did not open or are subscibed too are stil shown to me
[08:18] <persia> The list commented bugs contains all the bugs you ever touched: it's non-editable.
[08:18] <persia> You can change subscription for bugs to which you are directly subscribed, and change structural subscriptions (e.g. package subscriptions) for packages that no longer interest you.
[08:18] <janimo> persia, I am sure I have touched more than 82 bugs, hence the list looks almost random
[08:19] <janimo> persia, I have no package subs, but I still get xfce/xubuntu related bugs there
[08:19] <janimo> hmm I guess it only shows open bugs
[08:19] <janimo> thats's why it is 82
[08:20] <janimo> also if I open a bug, then an also affects link is set, then even if mine is close in ubuntu, the bug is shown until that other project (which may not be actively maitained) fixes it too
[08:21] <persia> Yes, there's no way to make the bug go away until all tasks are closed unless you intentionally unsubscribe.
[08:22] <persia> Which gets annoying in the case of structural subscriptions.
[08:22] <janimo> persia, but I am not subscribed directly
[08:22] <persia> Commented Bugs shows only 66 for me, but maybe I can't see some of yours :)
[08:22] <janimo> that is why I feel I cannot make these go away at all
[08:22]  * persia picks bug 65556 at random
[08:23] <janimo> persia, right only 66
[08:23] <janimo> those make up the bulk of all related bugs. I was on that poage and misquted the number
[08:25]  * janimo would love to have overlooked a way to get rid of the unwanted bugs
[08:27] <persia> Hrm.  I've no idea for the sample bug I picked.  I can't see how or why you are subscribed.
[08:27] <janimo> persia, unfortunatley it is the same for many of those bugs - at one point I was subscribed to all xfce/xubuntu ones
[08:27] <janimo> shall I ask on the lp ml?
[08:28] <persia> Someone more knowledgeable will probably comment soon.
[08:29] <persia> If nobody does, prod the help contact next time one is listed in the /topic (there is one listed for some random 40 hours each week, depending on timezones).
[08:29] <persia> If that doesn't work, or you don't want to wait, file an answer at answers.launchpad.net/launchpad
[08:30] <janimo> persia, ok thank you
[08:30] <persia> Good luck.
[13:04] <janimo> bac, hi
[13:05] <bac> hi JanC
[13:05] <bac> sorry janc, hi janimo
[13:05] <janimo> bac, do you have scrollback? If not I'll paste here my questin again :)
[13:05]  * bac looks
[13:06] <janimo> luckily the channle was quiet since I had written
[13:08] <bac> janimo: what is your LP id?
[13:08] <janimo> jani
[13:09] <janimo> bac, I have since made a few bugs invalid, and unsubscribed from those I could, but still there are a few (xfce mostly) I can't do anyting about
[13:11] <bac> janimo: so you are getting mail for the bugs listed in "List commented bugs" even though you are not subscribed?
[13:12] <janimo> bac, I don;think I get mails, some are not touched by anyone for 2-3 years
[13:12] <janimo> but they show up in my default bug page, making the ones that I care about harder to locate
[13:13] <bac> janimo: ok, so your "List related bugs" shows old bugs you commented on but are no longer interested in.  is that right?
[13:13] <janimo> yes
[13:14] <janimo> the default page https://bugs.launchpad.net/~jani
[13:14] <janimo> if the default page would be list subscribed or assigned it would be a good workaround
[13:16] <bac> janimo: the "list related bugs" is a superset of all of the other bug lists, like subscribed, commented, etc
[13:16] <bac> janimo: it is the default shown for an individual, ATM and is not configurable
[13:16] <janimo> bac, so what I see is notmal behaviour? ok then
[13:16] <janimo> thank you
[13:17] <bac> so, i think if it isn't showing the info you need, you'll need to select the list you are interested in, such as 'subscribed' or 'reported'
[13:17] <janimo> I would have expected the default to be a smaller set - assigned for instance
[13:17] <janimo> ok
[13:17] <bac> janimo: you can make a strong argument for that!
[13:19] <bac> janimo: please open a bug if you think the behavior is wrong or confusing.
[13:21] <janimo> I will (although I unsubed from about 4-5 LP bugs I opened in the past 5 years since there was no action on them)
[13:25] <janimo> bac, filed https://bugs.launchpad.net/launchpad/+bug/713092
[13:27] <bac> janimo: my squad is doing a big rework of how subscriptions work, so look for more control in the future.
[13:27] <janimo> bac, great
[13:27] <janimo> any cleaning and pruning of the bug lists help
[13:28]  * janimo grumbles at also-affects which creates duplicates and sticks along even if in the original project there's a Fix released
[17:36] <shadeslayer> hi
[17:36] <shadeslayer> can someone unset the bzr branch from https://code.launchpad.net/libktorrent/trunk
[17:37] <shadeslayer> https://code.launchpad.net/~neon/libktorrent/master is the new trunk
[17:43] <jelmer> shadeslayer: hi
[17:43] <shadeslayer> jelmer: omg ... i need to buy you a beer dude
[17:43] <jelmer> shadeslayer: heh
[17:43] <jelmer> shadeslayer: are you going to be at FOSDEM ? >-)
[17:43] <shadeslayer> no seriously ... :P
[17:43] <shadeslayer> too far :(
[17:44] <shadeslayer> jelmer: why didn't you come to UDS N?
[17:44] <jelmer> shadeslayer: I was at a different conference at the time.
[17:44] <jelmer> shadeslayer: Whereabouts are you based?
[17:44] <shadeslayer> ah
[17:44] <shadeslayer> jelmer: Gurgaon, India
[17:45] <jelmer> ah
[17:50] <shadeslayer> jelmer: thanks to you fixing that mem bug, we can automate more builds, instead of having to upload them manually ;)
[17:51] <yofel> well, now we only have 2 recipes that don't work for LP reasons, well, one works randomly
[18:03] <shadeslayer> jelmer: https://code.launchpad.net/~neon/ktorrent/master << same thing for ktorrent too
[18:03] <shadeslayer> https://code.launchpad.net/~neon/ktorrent/trunk
[19:27] <bcurtiswx_> just running an idea by to ya'll.  How hard would it be to see the bug status and importance in bug e-mails.  I see this being important, as if i'm reading through a backlog of bug mail, if I notice a response of a bug thats already in a triaged state and I see the response adds nothing I can just delete the email.  This way I don't have to go into the bug report to check this out
[19:28] <brov> hello
[19:29] <brov> how much time will take a review of SVN import ?
[19:30] <bcurtiswx_> for example as well, i get bug mail from https://bugs.launchpad.net/ubuntu/+source/papyon/+bug/631428 where empathy is in an invalid state and other packages have been assigned.  these type of bug mails i can ignore and don't want to load the launchpad page for it
[19:30] <brov> (I registered a branch and trying to import from SVN and it says 'pending review')
[19:52] <maxb> brov: There's no set schedule, however, if you mention you're waiting in here, it tends to happen quickly. If you don't, it can take several days
[19:52]  * maxb reviews brov's import
[19:52] <brov> ok, thanks
[19:53] <maxb> brov: The url needs to be one to a specific branch in the svn repo, not the repo root. I guess you want the trunk?
[19:53] <brov> yeah
[19:54] <brov> I'd like to add /branch/Rewrite as well, but wiki says it's not possible atm :D
[19:54] <maxb> it does?
[19:54] <brov> yep
[19:54] <brov> a sec
[19:54] <maxb> Actually, bzr-svn may have problems understanding that it's a branch, because it's named wrongly
[19:54] <maxb> Standard svn convention says it should be /branches/ not /branch/
[19:54] <brov> https://help.launchpad.net/VcsImports
[19:55] <brov> "At the moment the service is restricted to tracking only the main branch of each project. "
[19:56] <brov> well, if it is possible then I could (in theory) give it a direct url to that branch, right?
[19:56] <maxb> Yes, but it may not understand what to do with it
[19:57] <brov> hmm, renaming 'branch' to 'branches' will do the job? :D
[19:57] <brov> will it be imported as well?
[19:57] <maxb> It should, and will assist people who are used to the standard conventions too.
[19:58] <brov> ok, renaming that folder then
[20:06] <brov> maxb: ok, renamed
[20:07] <maxb> I have rewritten the sentence that said "At the moment the service is restricted to tracking only the main branch of each project. "
[20:10] <shadeslayer> could someone set https://code.launchpad.net/ktorrent/trunk to point to https://code.launchpad.net/~neon/ktorrent/master
[20:10] <shadeslayer> so that i can delete https://code.launchpad.net/~neon/ktorrent/trunk
[20:11] <maxb> brov: Unfortunately there's a problem with importing from SourceForge at the moment, because they seem to be using an invalid or odd SSL certificate
[20:12] <shadeslayer> oh perfect for my test case ^^
[20:12] <brov> well, they use *.svn.sourceforge.net
[20:12] <shadeslayer> maxb: just for the imports?
[20:12] <shadeslayer> or the whole site?
[20:12] <maxb> brov: you will need to individually request the import of the branch too, if you want it
[20:12] <brov> not *.svn.sf.net
[20:12] <brov> so that's why I gave full url
[20:12] <maxb> shadeslayer: imports. svn does not like the certificate
[20:12] <shadeslayer> ah
[20:13] <shadeslayer> ok ... night all ... cya tomorrow
[20:13] <brov> maxb: can I request just /branches ?
[20:13] <maxb> no, only actual branches. - so, /branches/Rewrite
[20:13] <brov> kk
[20:13] <brov> ty
[20:14] <brov> requesting then
[20:14] <brov> :D
[20:15] <brov> hmm
[20:16] <brov> ok, requested
[20:16] <brov> I'm wondering if it will work with svn:// style url...
[20:19] <brov> it seems that sf does not support svnserve ...
[20:24] <brov> maxb: their cert _seems_ to be ok...
[20:27] <lifeless> brov: http://sourceforge.net/apps/trac/sourceforge/ticket/17134
[20:28] <brov> well, yeah
[20:28] <brov> I forgot I imported it some time ago:D
[20:37] <brov> maxb: can you change the url scheme to http:// and try again?
[20:37] <maxb> I did, it failed.
[20:38] <maxb> SF have very low timeouts on their http non-ssl connections which break the imports that way too
[20:40] <brov> hmm
[20:40] <brov> so shitty sf :P
[20:41] <brov> can't you import their cert manually? at least until they will fix it
[20:52] <brov> anyway, thanks for an assistance, maxb
[21:21] <brov> maxb: still around?
[21:21] <maxb> hi
[21:22] <brov> the other member of the project asked sf staff about it
[21:22] <brov> and sf has certs updated
[21:23] <brov> (at least they said so)
[21:23] <maxb> Doesn't look like it to me
 you should have launchpad fix it
 we updated certs
[21:29] <maxb> brov: "updated" can mean many things. Apparently here it does not mean "fixed"
[21:29] <maxb> Where is this conversation going on?
[21:29] <brov> #sourceforge
[21:29] <brov> on freenode
[21:34] <brov> dumb...
[21:38] <lifeless> frontline support & its the weekend
[21:39] <lifeless> I rather suspect sourceforge had their hand forced by the attack
[21:39] <lifeless> and testing they might normally have done got skipped/fastttracked
[21:40] <brov> well, that guy was right saying that could be done on lp end
[21:40] <brov> but... they must update their end as well
[21:41] <smokex> it is rediculous to have to work around it
[21:41] <lifeless> so, it would be insecure to accept certs that the ssl stack is rejecting
[21:41] <brov> yeah
[21:41] <brov> aggreed
[21:41] <lifeless> I don't think we'll do that, not as a general policy
[21:41] <smokex> oh we have channels here btw brov :)
[21:42] <brov> one more thing like this dumb answer
[21:42] <smokex> our group isn't officially registered with freenode though
[21:42] <brov> and I'm moving our project to lp