[12:11] <hawkaloogie> how would I go about using launchpad to develop a seemingly abandoned gnome project? (gftp to be precise)
[12:11] <hawkaloogie> maybe i should stfw first...
[02:30] <mpt> hawkaloogie, I think the recommended process is for your to e-mail the launchpad-users@ list with evidence of the current maintainers' inactivity and your activity
[03:55] <hawkaloogie> mpt, there is no current maintainer outside of the Gnome-Bugfixer-Guys, but before i make a monumental decision like taking over the project, i'm going to actually checkout and play with the code (seems prudent)
[04:00] <mpt> Gooooooooooooooooooood afternoon Launchpadders!
[04:16] <mpt> hawkaloogie, that seems like a good plan -- have fun :-)
[04:17] <hawkaloogie> mpt, oh i intend to, so many FTP programs are so far ahead of gftp... but first to fix it's pesky strange bugs
[04:18] <jamesh> hawkaloogie: why not just use nautilus? :)
[04:18] <hawkaloogie> nautilus is a file manager?
[04:18] <jamesh> yeah
[04:18] <hawkaloogie> not an ftp client?
[04:19] <hawkaloogie> i was wondering actually if the gnome project just decided to abandon gftp as deprecated since nautilus has ftp support
[04:20] <jamesh> hawkaloogie: I don't think gftp was ever officially part of the desktop
[04:20] <mpt> That's what I was wondering
[04:20] <jamesh> (that isn't saying anything about the quality of the gftp code -- there are a lot of programs not in the desktop set)
[04:20] <hawkaloogie> well now that would explain just about everything... except my stupidity
[04:21] <hawkaloogie> and that the gnome bugzilla hasn't had a patch commit in about 6 months
[04:26] <mpt> Maybe Launchpad's description of gftp could be updated to mention its obsolescence, if true
[04:27] <hawkaloogie> it doesn't seem to be obsolete, it seems simple to be abandoned
[04:29] <hawkaloogie> besides, imho users would be more familiar working with a gui ftp program instead of using a file manager. even if it'd actually wind up being easier to use nautilus
[04:50] <mpt> I doubt that, myself
[04:50] <mpt> FTP directories are just folders that happen to be somewhere else
[04:50] <mpt> all the same operations apply - copying, moving, renaming, making links, deleting
[04:52] <mpt> Windows Explorer does read/write FTP, Mac OS Finder does read-only FTP (and I suspect the only reason it doesn't do write FTP is to keep alive a software company whose only other major product was rendered irrelevant by iTunes ... but I digress)
[05:18] <hawkaloogie> but... queuing? resuming? recursing? the ability to have two file lists and navigate them simultaneously (double-clicking a folder in one side also transfers to the folder on the otre side)
[05:26] <jamesh> one thing that pisses me off more than telemarketers is telemarketers using badly configured predictive dialing software
[05:52] <mpt> hawkaloogie, Nautilus should (but probably doesn't) do queuing for moves/copies to the same device anyway
[05:52] <mpt> and, arguably, it should also have a two-pane view :-)
[05:53] <mpt> If I understand you correctly, it already does recursing, that's a pretty basic file manager operation
[05:57] <hawkaloogie> yeah, in essence it does everything if you get used to it
[06:17] <mpt> spiv, how's bug 39814 going?
[06:17] <Ubugtu> Malone bug 39814 in launchpad "Misleading login hint" [Medium,Confirmed]  http://launchpad.net/bugs/39814
[08:24] <carlos> morning
[08:40] <mpt> hi carlos
[08:41] <carlos> mpt: how's going?
[08:41] <spiv> mpt: slowly, but I'm doing it now.
[08:47] <mpt> spiv, yay
[08:47] <mpt> Does it need to be done separately for each wiki?
[08:49] <spiv> mpt: Yes, it's a change to the code of the wiki.
[08:49] <spiv> And it appears the code I have is different to the code on the actual wikis here.
[08:50] <spiv> (my copy doesn't have the "create an account" link)
[08:51] <spiv> It's a trivial enough change that the admins ought to be able to do it regardless, so I'm writing up a the RT request now, but at some point we should reconcile the differences between the running copy and what I've been hacking on.
[08:53] <spiv> Actually, I think the bug discussion is missing the real cause of the problem.
[08:54] <spiv> I think the hint isn't the main problem, it's that the field is labelled "Name" rather than "E-mail address".
[08:54] <mpt> indeed
[08:54] <spiv> The launchpad form has no such hint, just correctly labelled fields, and seems to work fine :)
[08:54] <mpt> (I thought the word "hint" was the result of non-native English writers)
[09:00] <spiv> mpt: (btw, you can actually use your launchpad name for the wiki login form too, but not the wikiname.  I really wish we didn't have a seperate wikiname for people...)
[09:02] <mpt> spiv, so you can use your Launchpad name to log in to the wiki, but not to log in to Launchpad?
[09:02] <spiv> mpt: Yes :)
[09:02] <spiv> mpt: This is a "feature" of the authserver
[09:03] <jamesh> spiv: if we got rid of the salt for the password field, you could just ignore the username altogether and do a lookup by password
[09:03] <spiv> mpt: Seeing as we don't accept that for the main webapp, I should remove it, but it's not publicised so no-one ever notices...
[09:03] <spiv> jamesh: Haha, thinking back to the SSH key idea from the other day? ;)
[09:04] <mpt> spiv, I did report a bug once that you should be able to use your ID to log in to Launchpad, but LaunchpadLoginService makes it probably not a good idea
[09:04] <jamesh> spiv: actually, all we need to do is ensure that the same salt is used for every password :)
[09:06] <spiv> mpt: do you have a link for that?
[09:06] <spiv> Ah, I think I found iit.
[09:08] <mpt> Canonical wiki
[09:10] <spiv> I don't see how it matters to LaunchpadLoginService whether you use 'mpt' or 'mpt@canonical.com'.
[09:11] <mpt> spiv, for other services that don't have personal URLs, we won't want to expose IDs, so we can talk about e-mail addresses exclusively
[09:11] <spiv> (I can see that it's desirable to keep accepting only email address, because it's simpler to describe and means users don't need to remember yet another login name, but that's orthogonal)
[09:12] <spiv> Ah.
[09:12] <jamesh> spiv: we don't need to tell people that we accept short user ids ...
[09:13] <spiv> That makes sense, although I don't think it's fundamentally necessary.
[09:13] <spiv> mpt: Ideally, that means we get rid of wikinames ;)
[09:13] <mpt> spiv, that would require heavier hacking of MoinMoin's history function etc, right?
[09:13] <spiv> mpt: not at all.
[09:13] <jamesh> spiv: maybe user IDs in wiki page change logs should link through to launchpad.net?
[09:14] <jamesh> that's the main place where you still see wiki names
[09:14] <mpt> spiv, so what would the author of changes be shown as?
[09:14] <spiv> mpt: Moin is actually quite senisble about storing that info by internal user ID.
[09:14] <mpt> ok
[09:14] <spiv> mpt: Whatever handle we tell Moin to use.
[09:14] <spiv> jamesh: That could work.
[09:15] <spiv> Anyway, I already fought against wikinames and lost, I should just give up :)
[09:17] <jamesh> spiv: if we made Launchpad an OpenID server, it would make even more sense
[09:17] <jamesh> since you'd be using the person page URL as a user ID to log into other sites
[09:17] <spiv> jamesh: yeah, I completely agree.
[09:18] <spiv> Incidentally, see https://wiki.ubuntu.com/LaunchPadMultiLogin
[09:19] <mpt> heh
[09:55] <siretart> is https://wiki.launchpad.canonical.com/AuthServer usable for the public now?
[09:56] <jamesh> siretart: no
[09:57] <jamesh> siretart: probably won't ever be.  We have been considering OpenID though
[10:00] <siretart> jamesh: what do I need to request access to the AuthServer? I was told to open a RT ticket, but I don't know how
[10:00] <spiv> siretart: what do you need access for?
[10:00] <siretart> spiv: for Authentication of users, for REVU
[10:01] <spiv> siretart: is that hosted in the Canonical datacentre?
[10:01] <jamesh> siretart: unless things have changed, I don't think you'd be given access to it -- the protocol isn't really suited for the open internet
[10:01] <siretart> spiv: no. It is however on a canonical sponsored server: 69.60.114.100
[10:02] <spiv> Yeah, I don't think you're likely to get authserver access.
[10:03] <siretart> well, it was an approved spec, even approved by sabdfl
[10:03] <jamesh> siretart: your app sounds like a good reason to get the OpenID stuff done
[10:04] <spiv> If your system were compromised, it would allow someone to get privileges to hijack accounts, and do things like upload malicious packages and view security-sensitive bugs.
[10:04] <spiv> hijack launchpad accounts, that is.
[10:05] <spiv> To allow you to authenticate against Launchpad without exposing us to that sort or risk, we need to provide OpenID like jamesh says.
[10:05] <jamesh> siretart: with OpenID, your app would never see LP passwords, as the user would be bounced to https://launchpad.net for auth
[10:05] <lifeless> spiv: the authserver can change passwords ?
[10:05] <siretart> so access to the authserver implies access like "su'ing" to other user ids without a password?!
[10:05] <jamesh> siretart: which also means that the user can get some idea of what site is trying to auth them
[10:06] <spiv> lifeless: it can, but even without that there's password sniffing if we let other people's login boxes sit between users and Launchpad.
[10:06] <jamesh> lifeless: if he was using the authserver, then users would be sending their LP login credentials to his site
[10:06] <jamesh> lifeless: we don't want to get people used to entering their LP credentials on random sites
[10:06] <ruffneck> http://volny.cz/ropucha_3000/hitlatuma.swf
[10:06] <lifeless> jamesh: ack
[10:07] <siretart> hm. I see. then I'll need to keep an authentication db. I will think about something else
[10:07] <siretart> currently, I generated gpg keyrings from a launchpad group using rdf parsing
[10:08] <siretart> perhaps I can require users to set a password using a gpg signed message or something
[10:09] <siretart> or don't require a password for commenting uploads at all. we'll see..
[10:10] <jamesh> siretart: https://launchpad.net/people/$USERID/+rdf will give you the list of keys the user has registered with LP, if that helps.
[10:10] <siretart> jamesh: thats what I'm parsing right now. Thanks
[10:14] <jamesh> siretart: when the OpenID stuff is done, the user interaction would basically be that you get the user to enter their OpenID URL and redirect them to the page the OpenID server specifies.  That site asks the user if they want to authenticate to your site and if so redirects back to the URL you specify.
[10:14] <jamesh> siretart: if they've already said they want to auth to your site, the auth form would be skipped.
[10:15] <jamesh> you'd be able to limit it to LP user names by constructing an OpenID URL from an LP user name
[10:15] <jamesh> rather than accepting arbitrary URLs
[10:19] <siretart> jamesh: is there an spec for the openid stuff? what priority does it have?
[10:21] <jamesh> siretart: http://openid.net/ is the protocol I'm talking about
[10:21] <jamesh> siretart: the LP implementation isn't a high priority at the moment.
[10:26] <lifeless> spiv: jamesh which one of you wants to run the review meeting today ?
[10:27] <jamesh> I think I was volunteered last week, which is okay with me
[10:27] <lifeless> cool
[10:27] <lifeless> so there is a topic in this weeks one, which I probably will be to busy to present
[10:27] <lifeless> right now steve and I are preppig, so I can tell you about it now
[10:29] <lifeless> the topic is some branches need specs
[10:29] <lifeless> this is related to the lp meeting emphasis on pre-code reviews
[10:29] <lifeless> erm, pre-code voip calls
[10:30] <lifeless> and the idea is that one thing reviewers doing pre-code calls should do, os consider whether sufficient discussion/planning/whatever has occurred for the feature
[10:30] <lifeless> that is, if someone is working on bug X, we should spend a very small amount o time to be sure that we dont actually need a spec X fist
[10:32] <lifeless> jamesh: ^
[10:32] <jamesh> okay
[10:32] <lifeless> SteveA: you are obsessed with fisting
[10:33] <lifeless> I'd like the team to discuss it, and if it makes snense we'll start doing this, if you feel its really not an issue, then we can just carry on as per
[12:03] <mpt> hi SteveA
[12:27] <ploum> hello
[12:28] <ploum> I'm progressing in my Launchpad frontend Summer Of Code
[12:28] <ploum> And I will soon implement the protocol support
[12:28] <ploum> Can I hope about a sort of protocol to speak with launchpad ?
[12:29] <ploum> or will I have to parse webpage via http ?
[12:31] <stub> We export some information as XML and are starting on adding XML-RPC methods. You can expect things to break parsing the web pages - if the information you need isn't available submit bug reports requesting it.
[12:32] <sivang> morning
[12:32] <stub> I think it is mainly bug information that is available at the moment - Bjorn or Brad should know more if that is the area you are dealing with.
[12:34] <ploum> stub: indeed, I deal only with bugs ATM
[12:34] <ploum> I will contact them
[12:35] <mpt> SteveA, unping, bedtime for me
[12:35] <ploum> thanks
[12:35] <spiv> ploum: There's also https://launchpad.net/bugs/<bug number>/+text
[12:36] <mpt> ploum, https://launchpad.net/bugs/1/+text
[12:36] <Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  
[12:36] <mpt> oh, snap
[12:37] <ploum> spiv, mpt: thanks ! It can be helpfull as a temporary solution
[12:37] <ploum> but I also have to make searches and to modify bugs ;-)
[12:39] <stub> ploum: Who is your mentor for the project?
[12:43] <sivang> ploum: You could actually build your application such that there is a common contract to speak to a backend, then start with a backend that parses webpages via http, and then when launchpad grows a protocol like this, just code another backend.
[12:44] <stub> We need to provide the API anyway - I'd rather do it right the first time.
[12:45] <jamesh> reviewers meeting in 20 minutes
[12:46] <sivang> stub: sure :)
[01:03] <jamesh> spiv, BjornT: reviewers meeting?
[01:04] <BjornT> sure
[01:04] <jamesh> lifeless and SteveA are at EuroPython so probably won't be around
[01:04] <jamesh> don't know whether we are expecting salgado or not
[01:05] <SteveA> hi.  i'm not here.
[01:05] <lifeless> neither am I
[01:05] <jamesh> spiv: png?
[01:06] <jamesh> ping even
[01:06] <spiv> jamesh: pong
[01:06] <spiv> I'm here.
[01:06] <spiv> (got distracted by a review! :)
[01:07] <jamesh> == Agenda ==
[01:07] <jamesh>  * Roll call
[01:07] <jamesh>  * Agenda
[01:07] <jamesh>  * Next meeting
[01:07] <jamesh>  * Some branches need specs (RobertCollins if available, otherwise ???)
[01:07] <jamesh>  * Queue status.
[01:07] <jamesh> so, is everyone happy with the same time next week?
[01:08] <jamesh> 10th July, 11:00 UTC
[01:08] <BjornT> fine by me
[01:08] <spiv> Sure.
[01:08] <jamesh> lifeless: do you want to describe the next item, or are you still not here?
[01:09] <ploum> sivang: this is what I do, of course
 the topic is some branches need specs
 this is related to the lp meeting emphasis on pre-code reviews
 erm, pre-code voip calls
 and the idea is that one thing reviewers doing pre-code calls should do, os consider whether sufficient discussion/planning/whatever has occurred for the feature
 that is, if someone is working on bug X, we should spend a very small amount o time to be sure that we dont actually need a spec X fist
[01:09] <ploum> atm, I have a "dummy protocol" that send dummies informations
[01:10] <jamesh> lifeless wanted us to discuss this to see whether we thought it was a good idea.
[01:11] <jamesh> so if you do a pre-code call with someone and the work is non-trivial and has no spec, maybe suggest that a spec be done for it first.
[01:13] <spiv> I think it's a good idea.
[01:13] <BjornT> i think that's a good idea. sometimes it feels like just because someone reported a bug, it means that we should implement it without any discussion needed.
[01:14] <jamesh> okay.  So if anyone sees this sort of situation in a call, they should suggest doing a spec (if appropriate)
[01:14] <jamesh> please mention this in the followup email to the launchpad-reviews mailing list if it happens
[01:15] <jamesh> Last item on the agenda is queue status
[01:16] <spiv> I just moved carlos/launchpad/bug-50472 to merge-conditional a moment ago.
[01:16] <jamesh> the oldest reviews are assigned to kiko and salgado, who were at a sprint last week.  I guess they'll get to their ones this week
[01:17] <spiv> jamesh: even older is the post-merge review I promised for your bug-45987 branch :)
[01:17] <jamesh> I sent in a review for cprov's one earlier today, so ignoring the kiko's and salgado's the oldest is 2 days
[01:18] <jamesh> spiv: I missed that one ...
[01:19] <jamesh> So other than those three branches, things are looking pretty good as far as response times go
[01:19] <spiv> Yeah, it looks healthy to me.
[01:19] <jamesh> Does anyone have anything else to bring up?
[01:20] <BjornT> no, nothing from me
[01:20] <jamesh> okay. Meeting ends.
[01:20] <jamesh> thanks, everybody.
[01:38] <mdke> SteveA: I don't want to reply to your mail on the list, since you've declared it the end, but there is one complication
[01:38] <mdke> SteveA: the ubuntu mailing list guidelines ask people to avoid reply-to-all, and it might be considered an Ubuntu list, even if strictly speaking, it isn't
[01:46] <jamesh> mdke: I guess the Ubuntu mailing list guidelines should be fixed then :)
[01:48] <mdke> jamesh: I don't think so, there are good reasons for doing that. People who post via a newsreader or filter mail by mailing list headers get screwed by reply-to-all.
[01:48] <mdke> where screwed = getting unwanted mail in their inbox
[03:08] <carlos> later
[03:23] <Yannig> Hello everybody :)
[03:27] <jsgotangco> good evening :)
[03:44] <stub> sabdfl: Did you need those blueprint updates you committed on the weekend to be rolled out tomorrow?
[04:06] <elmo> who's responsible for (in the sense of who gets bugs for) https://launchpad.net/distros ?
[04:08] <malcc> Soyuz UI, therefore cprov and me
[04:09] <elmo> malcc: which product should I file a bug on ?
[04:09] <malcc> elmo: Soyuz
[04:17] <elmo> malcc: thanks
[04:55] <Keybuk> BjornT: ping?
[04:55] <BjornT> Keybuk: pong
[04:55] <Keybuk> BjornT: why do I get bug mail for bug #1 ?
[04:55] <Ubugtu> Malone bug 1 in Ubuntu Dapper "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[04:56] <Keybuk> I'm not subscribed
[04:56] <Keybuk> yet I'm in the list as "Also Notified"
[04:59] <BjornT> Keybuk: that's because you are the bug contact for sysvinit. there's a bug open on that you at least should be able to unsubscribe from the bug in such cases.
[05:00] <Keybuk> BjornT: but what has that got to do with sysvinit?
[05:00] <BjornT> Keybuk: bug 49687
[05:00] <Ubugtu> Malone bug 49687 in malone "allow unsubscribing implicit subscribers" [Medium,Confirmed]  http://launchpad.net/bugs/49687
[05:00] <Keybuk> the bug isn't linked to sysvinit at all
[05:00] <Keybuk> oh, it's rejected
[05:00] <BjornT> yeah
[05:01] <Keybuk> so if I change that rejected task to something else
[05:01] <Keybuk> I won't get mail?
[05:01] <BjornT> yeah, that's right.
[05:15] <Korsaire> Hello
[05:41] <ploum> can someone point me to the XMLRPC documentation of Malone ?
[05:45] <BjornT> ploum: malone has no xmlrpc interface currently, so there is no documentation about it.
[05:45] <ploum> BjornT: argh !  I thought that...
[05:45] <ploum> erf
[05:45] <ploum> There is no way to access data besides http ?
[05:46] <ploum> (html)
[05:46] <ploum> seb128 just told me that there was one
[05:49] <ploum> (and I saw it on http://www.mail-archive.com/launchpad-users@lists.canonical.com/msg00262.html )
[05:50] <carlos> ploum: we are working on it, but we don't have anything available to the public yet
[05:51] <ploum> Do you know when we can expect something ?
[05:51] <carlos> ploum: you will need to wait for BjornT to answer that
[05:51] <ploum> My Summer Of Code is a launchpad interface...
[05:51] <ploum> I "could" parse webpage and send http request but that would be suboptimal
[05:52] <ploum> (and a lot of work too)
[05:52] <carlos> ploum: the XML-RPC we are working on is not for the whole launchpad
[05:53] <ploum> sorry, my SoC is in fact only on Malone for the moment
[05:54] <carlos> SteveA, BjornT: Do you know if zope has a way to sort a batched list like we do now with javascript but as a server process?
[05:54] <BjornT> ploum: you can access bug data using for example /bugs/42/+text. you can also get bug lists, for example /products/launchpad/+bugs-text. i can't find any documentation about it, though, and the format might change in the future.
[05:54] <carlos> ploum: then you will need to talk with BjornT, I don't know all details about it
[05:55] <ploum> BjornT: is there something similar for search results ?
[05:56] <BjornT> ploum: i think so, but i'm not sure. try doing a search and replace +bugs with +bugs-text
[05:56] <ploum> ok, I will try this
[05:59] <BjornT> ploum: as for the xmlrpc interface mentioned in the mail, the documentation is at http://bazaar-vcs.org/Specs/BranchRegistrationTool. but it's probably not useful for you.
[05:59] <ploum> BjornT: waaaa ! it works !
[06:00] <ploum> https://launchpad.net/distros/ubuntu/+bugs-text?field.searchtext=evolution&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&field.status%3Alist=Needs+Info&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[06:00] <ploum> (sorry for the long url)
[06:02] <BjornT> carlos: well, you could reload the whole page... if that's not enough you'll have to use ajax, and should provide reloading the page as a fallback anyway.
[06:08] <carlos> BjornT: yeah, I know. What I'm asking is whether we have code to do that already or we should implement our own thing
[06:24] <BjornT> carlos: the bug listings are sorted server side, but there's no general infrastructure to use.
[06:25] <carlos> BjornT: do you think we could reuse it? or is it too specific?
[06:29] <BjornT> carlos: i think it's quite hard to reuse it. it could be done by refactoring out some functionality, but it's probably not worth the effort.
[06:30] <carlos> so we should implement it with every form
[08:40] <carlos> see you!!
[09:20] <ploum> BjornT: the +bugs-text interface is not working ! it always send the same numbers
[09:20] <ploum> (and it's a huge list)
[09:44] <dooglus> murhy: if you want to move the whole torrent in one go, right click the torrent in the download list, then advanced -> files -> move data files.  you'll have to stop the torrent file first, or it won't let you.
[09:45] <dooglus> um...
[09:45] <dooglus> sorry.
[10:07] <ploum> sivang: ping
[10:30] <sivang> ploum: pong
[11:01] <mpt> Gooooooooooooooooooooooood morning Launchpadders!
[11:13] <ploum> mpt: good night too