[00:40] <lfaraone> doctormo: hey, why does groundcontrol depend on python-lazr-uri ?
 doctormo: hey, why does groundcontrol depend on python-lazr-uri ?
[01:00] <thumper> doctormo: said just before you turned up
[01:01] <doctormo> thumper: thanks
[01:02] <doctormo> lfaraone: It's because of the cleaning of the launchpad lib domain name in base.py the code that showed how to do it uses lazr.uri.URI
[01:06] <_Groo_> hi/2 all
[01:06] <_Groo_> any dev alive?
[01:06] <_Groo_> could anyone confirm if uploads to ppa are working? i cant upload anything for more then 2 weeks now
[01:06] <wgrant> _Groo_: Yes, uploads are fine.
[01:06] <wgrant> _Groo_: Is this the issue where an upload hangs just before it should finish?
[01:07] <_Groo_> wgrant: yes but its worse now, it hangs right after the first 17k
[01:07] <wgrant> _Groo_: A router somewhere between you and Launchpad is most probably buggy.
[01:07] <_Groo_> wgrant: how can i check this?
[01:08] <wgrant> _Groo_: I don't know. But something is breaking your FTP uploads, and it's not Launchpad.
[01:08] <_Groo_> wgrant: can i upload them directly via ncftp?
[01:09] <wgrant> _Groo_: As long as you do it in one FTP session, yes.
[01:09] <wgrant> _Groo_: Upload the .changes file and everything referenced therein.
[01:09] <_Groo_> wgrant: ok gonna try it
[01:11] <_Groo_> wgrant: so i upload .changes, .dsc and everythng else referecend there?
[01:11] <wgrant> _Groo_: Correct.
[01:12] <_Groo_> wgrant: the changes you mean, is the source_changes file, not the original changes, right?
[01:12] <wgrant> _Groo_: The original changes? What do you mean?
[01:14] <_Groo_> wgrant: when i make the package locally i have a .changes file, when i do a debuild -S -sa it makes a source.changes file, thats the one correct?
[01:14] <_Groo_> ncftp ...miguel-dias/ppa/ubuntu > put skrooge_0.6.0.6-0~padoka1_source.changes skrooge_0.6.0.6.orig.tar.gz skrooge_0.6.0.6-0~padoka1.diff.gz
[01:14] <_Groo_> ...0.6-0~padoka1_source.changes:  ETA:   0:00    1.54/  1.54 kB   15.23 B/s =
[01:14] <_Groo_> yeah it doesnt work... it hangs in the first 1k :(
[01:14] <_Groo_> i can connect via ncftp, even change dirs, but i cant upload :(
[01:15] <wgrant> _Groo_: Have you tried uploading to other places?
[01:16] <_Groo_> wgrant: let me try revu
[01:17] <_Groo_>   Uploading skrooge_0.6.0.6.orig.tar.gz: 18k/7600k
[01:17] <_Groo_> it goes but very VERY slow still it stalls
[01:17] <wgrant> That more strongly suggests that it's a problem at your end.
[01:19] <wgrant> (REVU runs a different FTP server, and is in a different country on a completely independent network)
[01:23] <_Groo_> can i upload with any other protocol? even experimental one, like rsync or ssh?
[01:23] <wgrant> No. Only FTP is available at this time.
[01:24] <wgrant> (SFTP will happen eventually, but it's not there yeT)
[01:28] <groo_> i fixed it!!!
[01:28] <groo_> finally!!!
[01:28] <wgrant> What did you do?
[01:28] <groo_> my ISP (telefonica) is a piece of 8hit
[01:28] <wgrant> Another host?
[01:28] <wgrant> Yeah...
[01:28] <groo_> nope, changes mtu
[01:29] <groo_> changed
[01:29] <wgrant> Ahh.
[01:29] <wgrant> Even better.
[01:29] <groo_> from the ieee 1492 to pppoe 1480
[01:29] <groo_> instantly started working!
[01:29] <wgrant> Excellent.
[01:29] <groo_>   Uploading skrooge_0.6.0.6.orig.tar.gz: 3836k/7600k
[01:30] <groo_> already going :)
[01:30] <groo_> why on earth isps dont oblige to standards!!!
[02:22] <RenatoSilva> whta if a given bug is fixed using a workaround, then you release your app, but later it is fixed upstream which breaks your workaround and a very similar bug is raised now (the old bug title/description perfectly matches the new bug)?
[02:22] <RenatoSilva> how about re-opening the old bug? or should we open a new bug?
[02:23] <persia> RenatoSilva: Depends on your preferred workflow.  I personally prefer to open a new bug.
[02:24] <RenatoSilva> persia: it seems the best idea to me too, I just wonder how would it "look like" if I reuse the bug
[02:24] <persia> The strongest rationale I've heard for reopening a bug is that there is already a link to a branch that shows the relevant code changes, making a fix potentially easier.
[02:24] <persia> My rationale for opening a new bug is that the comments/workaround/solution in the old bug are no longer either accurate or relevant, and may be confusing.
[02:24] <RenatoSilva> yes
[02:26] <RenatoSilva> but certaintly, the old bug is related to the new one and it's suitable they are somehow linked to each other
[02:26] <RenatoSilva> in fact, this is a real case happening to me
[02:27] <zul> i have a question is possible to pull a git branch from an external git tree in launchpad, for example say I want to pull in http://git.samba.org/?p=samba.git;a=shortlog;h=refs/heads/v3-4-test ?
[02:27] <persia> You could put a link in the description of the new bug "This behaviour is the same as that seen in bug #5858585858, as the workaround is no longer valid.", and LP will automatically turn the bug reference into a working hyperlink.
[02:27] <RenatoSilva> bug 464156 is actually a bug in Konqueror, but I gave up from waiting them to fix it, then I'm working on a workaround (see the comments etc)
[02:28] <RenatoSilva> however, I would really appreciate if they fix it later, but that will break the workaround
[02:28] <RenatoSilva> the workaround seems a good idea anyway, because with some code to detect version I can keep supporting the non-fixed version of Konqueror
[02:30] <RenatoSilva> http://launchpadlibrarian.net/34740924/Problem.png
[02:30] <RenatoSilva> http://launchpadlibrarian.net/34740927/Expected.png
[02:32] <RenatoSilva> thanks persia...
[02:32] <RenatoSilva> bbl
[02:32]  * RenatoSilva reboot
[03:25] <thumper> zul: I'm not sure I get what you are asking
[03:26] <wgrant> zul: bzr-git can't currently import non-master branches, but I think there's some work on that.
[06:31] <om26er> how can I download source from a ppa?
[06:33] <wgrant> om26er: Add the equivalent deb-src line to your sources.list and run 'apt-get source PACKAGE', or find the link on the PPA web UI.
[06:40] <om26er> thanks wgrant
[11:16] <Laney> mars: can you deal with my question 100737? FF is rapidly approaching
[11:21] <geser> bigjools: just curious: did you find out why clxclient didn't get synced to the LP Debian mirror? (it's not important if you don't have time for checking)
[11:21] <bigjools> geser: sorry I didn't get very far - I looked in the logs and there's no errors that I can see
[12:40] <spiderbatdad> adeuring, here, and may I pm?
[12:41] <spiderbatdad> other lp admin?
[12:45] <paissad> hi all, i would like to know if it's possible to upload a software whose source code is not available, i packaged it already !
[12:45] <maxb> spiderbatdad: Do you know if you actually need an admin? Usually, ping the help contact mentioned in the channel topic
[12:46] <paissad> is it forbidden by launchpad policy ?
[12:47] <paissad> the software is a freeware, ... btw
[12:47] <intellectronica> paissad: yes, it's forbidden. you may only upload software that is free.
[12:48] <paissad> intellectronica, even if it's a freeware ?
[12:48] <intellectronica> paissad: yes. only open source software, please
[12:49] <paissad> intellectronica, ok, thanks for the info
[12:49] <spiderbatdad> maxb, thanks i noticed mars is help contact. i'm unable to login to lp, so i think i need an admin
[12:53] <spiderbatdad> i'll try back in a few hours.
[13:33] <mars> Good morning Launchpad
[14:17] <sebner> wgrant: fixed dpkg is now merged into lucid but I'm strugelling about backporting it. After reading some old ML stuff I guess you are not using an official dpkg version on the build machines since the latest version on hardy is 1.14.16.6ubuntu4 (you spoke about 1.14.27 beeing necessary)
[14:37] <persia> sebner: You may want to ask questions more generally.  wgrant is very likely to be sleeping now, and furthermore isn't someone who can actually change that level of stuff.
[14:38] <sebner> persia: ah right, I just saw his name popping up several times regarding dpkg so I thought he would know what to do
[14:38] <persia> He is indeed, most knowledgeable :)
[14:39] <sebner> heh
[14:40] <sebner> persia: I did through old mailinglists and it really seems cjwatson made some "secret" feature backporting as there is no official backport and I doubt somebody would allow an official one. Grr, and now on holidays
[14:41] <persia> sebner: I don't think it's that secret.  I think there's a special archive that is used by the LP servers, with a different set of backports than is available in other places.
[14:41] <persia> Of course, I have no idea how to access this archive :)
[14:42] <sebner> persia: Myself even less so I had high hopes on wgrant :)
[15:35] <maxb> sebner: You might like to talk to bigjools, on the basis that he uploaded the dpkg to the launchpad PPA, which is used by people developing launchpad on hardy
[15:36]  * sebner throws an eye onto bigjools 
[15:36] <sebner> maxb: thx for the hint
[15:37]  * bigjools is reading backscroll
[15:37] <bigjools> you have a dpkg fix that you want backported, right?
[15:40] <sebner> bigjools: well, not exactly. cjwatson merged a fixed dpkg-version into lucid. I'm now wondering how it will make its way onto the build machines as you are using a custom build
[15:41] <bigjools> the build chroot will get the new one of course, but not the host
[15:41] <bigjools> what did it fix?
[15:49] <sebner> bigjools: e.g some packages can't be synced from Debian. Unpacking fails
[15:49] <sebner> bigjools: therefore the host need the fix
[15:50] <sebner> bigjools: http://paste.ubuntu.com/373384/
[15:51] <bigjools> sebner: let me chat to someone about this, I'll get back to you
[15:52] <sebner> bigjools: thanks :)
[16:13] <lamont> sebner: the buildds run dpkg inside the chroot, so if it's fixed in lucid, it's fixed in lucid.
[16:14] <lamont> or at least it should be
[16:15] <lamont> esp since the build in question is now built everywhere
[16:15] <sebner> lamont: the dpkg of the host system unpacks the source
[16:16] <lamont> no, no it doesn't
[16:16] <lamont> trust me
[16:16] <lamont> it used to be that way, that changed when v3 packages showed up and we decided it was easier to run dpkg-source in the chroot than to backport support for v3 packages to dapper
[16:17]  * sebner tries
[16:17] <lamont> alien-arena is built, and that's the one in the pastebin...
[16:18] <lamont> so we have an existance proof... if you have a ppa package that is affected, it just needs to be retried
[16:19] <sebner> lamont: the old version build. the new version failed to sync because of the unpack issue ;)
[16:19] <lamont> sebner: _that_ is a sync issue, not a buildd issue
[16:19] <sebner> lamont: the sync failed because dpkg on the host is buggy
[16:19] <lamont> exactly
[16:19] <lamont> thanks for the report
[16:21] <sebner> lamont: Rejected:
[16:21] <sebner> dpkg-source failed for alien-arena_7.33-2ubuntu1.dsc [return: 2]
[16:21] <sebner> [dpkg-source output:   dpkg-source: info: extracting alien-arena in alien-arena-7.33
[16:21] <sebner>   dpkg-source: info: unpacking alien-arena_7.33.orig.tar.gz
[16:21] <sebner>   dpkg-source: info: unpacking alien-arena_7.33-2ubuntu1.debian.tar.gz
[16:21] <sebner>   dpkg-source: info: applying launch-server_tool_debianization.patch]
[16:21] <sebner> ;)
[16:21] <sebner> lamont: persia is better suited to explain the issue
[16:22] <lamont> sebner: yep.  the initial "is fixed" was all about the buildds, not about the sync host
[16:22]  * persia will be able to do that in about 5 minutes
[16:22] <james_w> lamont: is there somewhere that we can record that I would like any dpkg backports to cocoplum to also be installed on jubany?
[16:22] <lamont> persia: what I really need is an RT with where to find cjwatson's fix for hardy's dpkg
[16:23] <sebner> lamont: yeah, I'm sorry for using the false word :)
[16:23] <persia> lamont: Oh.  That I can't get you.
[16:23] <lamont> james_w: RT "please add hardy-cat-mom to jubany, kthx" would do it.
[16:23] <lamont> james_w: a rationale would, of course, be expected.
[16:23] <sebner> lamont: We need one with higher powers and access to the private archive of the machines
[16:24] <james_w> lamont: ah, nice, thanks :-)
[16:24] <persia> lamont: The report we got before was that Soyuz was unable to accept the package, not that it couldn't be built once dispatched.
[16:24]  * sebner is again sorry for the missunderstanding
[16:24] <persia> lamont: There was a bug in Debian about differing behaviour with and without quilt that hit this package oddly.
[16:25] <persia> sebner: Have you resubmitted to a lucid PPA since the fixed dpkg hit lucid?
[16:26] <lamont> persia: bug 561237?
[16:26]  * persia is suspicious
[16:26] <lamont> that's the "quilt v3 hates that we didn't create a directory" bug
[16:26] <sebner> persia: just a minute ago
[16:28] <persia> lamont: I was advised it was debian bug #557667
[16:28] <persia> And that matches the behaviour I saw with pre-merge dpkg in lucid.
[16:29] <lamont> persia: who would be the right distro guy to tap for a backport of just that fix to hardy?
[16:29] <persia> lamont: cjwatson, who is unavailable until after FeatureFreeze
[16:30] <persia> lamont: Note that 557667 affects chrooted calls for some reason.
[16:31]  * lamont tries another victim
[16:31] <lamont> persia: evidence of the chrooted calls?
[16:32] <persia> lamont: email from Marc Bockschmidt in 557667 log and my local experience last week.
[16:32] <persia> (which state my machine can no longer meaningfully replicate)
[16:32] <lamont> interesting
[16:33]  * persia belatedly adds a missing 'r'
[16:36] <lamont> persia: is there a bug against it launchpad for this?
[16:36] <lamont> bigjools: and would that be soyuz, launchpad-buildd, or somewhere else?
[16:36] <persia> sebner: ?
[16:37] <sebner> hmm, *we* didn't file a bug as we thought about coordinating directly with cjwatson
[16:38] <persia> sebner: Verify with a new upload to the PPA to make sure, and then file the bug :)
[16:38] <sebner> persia: <sebner> persia: just a minute ago
[16:39] <sebner> persia: means, 15 minutes ago I made a test-upload to my PPA
[16:39] <persia> sebner: Then file the bug :)
[16:39] <sebner> persia: <lamont> bigjools: and would that be soyuz, launchpad-buildd, or somewhere else?   :D
[16:39] <persia> Yeah, but we can just file against "launchpad" for now, and it can move as needed.
[16:39] <persia> Tracking is good.
[16:40] <sebner> aye
[16:46] <sebner> persia: lamont : https://bugs.edge.launchpad.net/launchpad/+bug/522719
[16:47] <sebner> persia: I hope it's ok that I stole the bug title ^_^
[16:47] <persia> sebner: You may want to link it to 557667 :)
[16:47] <persia> (and quote the relevant bit of the dpkg changelog)
[16:48] <persia> 561237 is a similar and related, but slightly different issue.
[16:49] <sebner> persia: should I link to 561237 too?
[16:49] <persia> I wouldn't.
[16:50] <persia> I don't think that breaks chrooted buildds (from the log)
[16:50] <sebner> k
[16:51] <sebner> persia: you can participate in the bug too, Setting to Confirmed *muahaha*
[16:51] <persia> sebner: You overestimate my influence on launchpad
[16:52] <lamont> it probably belongs more to soyuz than to launchpad, but don't really care enough atm
[16:52] <lamont> rumor has it we may have a version of dpkg to deal with this tomorrow or thur
[16:53] <sebner> lamont: grrrrrrrr, FF is around :P
[16:53] <lamont> sebner: I expect we can stuff it through late this week, even with featurefreeze
[16:53] <sebner> persia: hmm? I just set it to Confirmed
[16:53] <sebner> lamont: aye, thx for your help
[16:54] <persia> sebner: I got an error when I tried.  No idea.
[16:54] <lamont> sebner: esp if you have it in a lucid ppa and happy and working on lucid and such
[16:54] <persia> lamont: We can't have it in a PPA, for the same reason it can't be in the archive :)  But it seems to work fine locally, as long as one builds in a supporting environment.
[16:55] <persia> sebner: If it's not all fixed in 31 hours, file the FFe: I'm sure it will be approved :)
[16:55] <sebner> lamont: Filing FFe is sooo annoying :P
[16:55] <sebner> persia: sure, it's just annoying ^^
[16:55] <sebner> persia: the -data package is already on the new version so it will be approved in order to unbreak it anywaays
[16:57] <persia> sebner: Right, which makes it an easy FFe (if annoying).
[16:58] <sebner> persia: personally I had never trouble to convince our -release team acking a FFE :P
[16:58] <persia> Yeah.  You're good at that :)
[16:59] <sebner> persia: I'm wondering how many packages are affected by this bug
[17:00] <persia> sebner: Wouldn't they all show up as sync failures?
[17:00] <sebner> persia: yes
[17:00]  * persia would expect the archive-admins to have made some noise about this if there were a significant number
[17:02] <sebner> hmm
[17:02] <sebner> maybe
[17:04] <bigjools> lamont: it's not a bug in Launchpad at all
[17:04] <bigjools> it's an RT to backport dpkg
[17:04] <lamont> bigjools: no, it's a bug to the distro team to backport dpkg
[17:04] <lamont> and then an RT to install it
[17:05] <bigjools> ok
[17:05] <lamont> so it's really a bug against dpkg
[17:05] <bigjools> wfm
[17:05] <bigjools> so re-target that bugtask :)
[17:05] <sebner> lamont: The problem is that there are no official dpkg backports but cherrypicked stuff for the sync/build machines
[17:05] <lamont> sebner: exactly
[17:08] <lamont> I will be so happy when lucid comes out
[17:08] <lamont> well, for at least a few months
[17:08] <sebner> heh
[17:09] <maxb> Why is the supersecret archive supersecret anyway, instead of just being a PPA?
[17:09] <lamont> maxb: long history behind that answer
[17:10] <lamont> it's more one of "we have this archive (which includes non-free stuff) that we use in the DC, we can just lob this in there" than any attempt at secrecy
[17:11] <lamont> the bits needed for this should definitely be in a PPA somewhere
[17:15] <persia> lamont: Maybe lucid-cat can be a PPA?
[17:16] <lamont> persia: no.  it still has non-free crap and such.  OTOH, practice since hardy has been mostly telling people that we need it in (1) current dev release and/or (2) a PPA somewhere.  I think we just need to have another ppa that we toss the stuff that can go into a ppa, uh, into.
[17:17] <persia> heh
[18:18] <mars> which team should handle an Ubuntu docs question filed against launchpad?
[18:18] <mars> is there an ubuntu-docs team or something?
[18:57] <AlanBell> evening all
[18:57] <mars> hi AlanBell
[18:57] <AlanBell> is this a good place to ask about the new login.ubuntu.com?
[18:58] <mars> good question
[18:58] <AlanBell> just trying to figure out the URL for my shiny new OpenID
[18:58] <AlanBell> if indeed I have one
[18:59] <mars> salgado, ^ do you know if OpenID is still delegated via LP?
[19:00] <salgado> mars, LP delegates to login.lp.net
[19:01] <AlanBell> I went to https://login.ubuntu.com/ and it knew who I was and I set my password (to what it was anyway)
[19:02] <AlanBell> I was kind of expecting it to tell me my new openID URL ending in ubuntu.com
[19:21] <Besnik> I'm having troubles validating translation strings which contain '%' sign
[19:22] <Besnik> A closer inspection under a text editor shows that the first letter of the word after '%' is highlighted with the same colour as the '%' itself.
[19:24] <mars> AlanBell, you might want to try in #ubuntu-website.  They may know who to talk to about the OpenID work on the ubuntu* domains.
[19:24] <Besnik> I substituted '%' with the UTF8 equivalent 'U+0025' but Launchpad stills complain about "a format specification for argument 1 doesn't exist in 'msgstr' "
[19:24] <mars> AlanBell, https://wiki.ubuntu.com/Website
[19:24] <Besnik> Any hints about overriding the validator?
[19:25] <Besnik> Or should this be reported? Or perhaps is an already known issue?
[19:25] <mars> Besnik, I know little about translations, but do you have to escape % signs as %%?
[19:25] <mars> that is what you do to add a % to any C-style string substitution.
[19:26] <AlanBell> mars: thanks, I submitted a question here too https://answers.launchpad.net/canonical-identity-provider/+question/101324
[19:27] <Besnik> mars, I know even less about escaping :)
[19:27] <Besnik> But the sign is used in that form in the original string
[19:28] <mars> Besnik, have you looked at https://help.launchpad.net/Translations/StartingToTranslate#Dealing%20with%20unusual%20characters ?
[19:28] <Besnik> Both PoEdit and Gedit shows it as a single '%' which I didn't even touched: it is of the form 100% and should stay like that into any translation as there's nothing to translate there
[19:29] <akheron> mars: regarding the yesterday's broken link, I filed a but about it: #522800
[19:29] <Besnik> mars, no I haven't, as I've being doing it offline with po editors or text editors and than upload to Launchpad
[19:30] <mars> akheron, that is great, thank you for doing that
[19:31] <Besnik> mars, I think my case doesn't qualify for that page
[19:32] <Besnik> the test complains about using 5 sign in its literal function
[19:32] <mars> hmm.  Besnik, the translations team is in Europe mostly, so they are not here to help.  Someone else in the channel may know, or perhaps someone in #ubuntu-translators ?
[19:33] <mars> https://wiki.ubuntu.com/Translations/Contact/#IRC%20channel
[19:34] <Besnik> mars, are you saying that this might be a translation problem and not a Launchpad parsing problem?
[19:35] <mars> Besnik, nope, just saying that someone in that channel has probably been working with translations in LP, and can provide a better answer.
[19:36] <mars> Besnik, or, if you don't mind waiting a bit, file a question directly to the Translations team using https://answers.edge.launchpad.net/rosetta/+addquestion
[19:36] <Besnik> I see. Well thank you for trying to help
[19:38] <mars> Besnik, filing an Answer is a good way to get in touch with them.
[21:36] <aquarius> I have a project which has, as its trunk branch, lp:~sil/projectname/trunk. I'd like to create an alias lp:projectname for that branch. How do I do that? I can never remember, and I can't find anything relevant on help.launchpad.net either
[21:37] <lifeless> make it a series
[21:37] <aquarius> I only have the dimmest understanding of what that means :)
[21:37] <aquarius> aha, "register a series"?
[21:37] <lifeless> well
[21:37] <lifeless> you should already have a trunk series
[21:37] <aquarius> https://edge.launchpad.net/rhythmbox-ubuntuone-music-store
[21:37] <lifeless> if this branch == that series, just set the branch for it
[21:38] <lifeless> click on the series name on that page, will take you to a page prompting for the branch
[21:39] <aquarius> er, it doesn't, unless I'm missing something
[21:40] <aquarius> there's "development focus: trunk series" on the left of the page, and "trunk" on top of the arrow thing under "Series and milestones" in the middle of the page, both of whch go to https://edge.launchpad.net/rhythmbox-ubuntuone-music-store/trunk, which says "The following branch has been registered as the mainline branch for this release series: lp:~sil/rhythmbox-ubuntuone-music-store/trunk"
[21:43] <lifeless> right
[21:43] <lifeless> then lp:r-u-m-s should be working.
[21:43] <lifeless> and btw, no way I'm ever typing that hell-long name out!
[21:44] <mars> aquarius, you have no idea how long I have been looking for an answer to that question :)
[21:44] <aquarius> it already works?
[21:44]  * aquarius tests
[21:45] <aquarius> aquarius@dell-desktop:~/canonical/rhythmbox-ubuntuone-music-store$ bzr branch lp:rhythmbox-ubuntuone-music-store w00t
[21:45] <aquarius> bzr: ERROR: Invalid url supplied to transport: "lp:rhythmbox-ubuntuone-music-store": The Ubuntu Music Store Rhythmbox plugin has no default branch.
[21:45] <aquarius> fail.
[21:45] <aquarius> it does not already work.
[21:45] <aquarius> :-)
[21:45] <lifeless> mars: so the 'development focus' series branch is 'lp:THING'
[21:45] <lifeless> mars: all series branches are lp:THING/SERIES
[21:46] <lifeless> aquarius: its a private branch.
[21:46] <lifeless> aquarius: you fail
[21:47] <mars> and that explanation of fail would also explain my problem with getting lp:pyslow to work...
[21:48] <aquarius> lifeless, I must have missed the really obvious documentation about how to do this properly, then ;-)
[21:48] <aquarius> that being the case, how can I fix it?
[21:48] <lifeless> aquarius: make it a public branch
[21:48] <lifeless> aquarius: the directory service that does lp: url lookups is anonymous and unauthenticated.
[21:48] <lifeless> aquarius: so it only handles public branches.
[21:49] <lifeless> aquarius: generally docs aren't needed for this because most things are public :>
[21:49]  * aquarius looks on https://code.edge.launchpad.net/~sil/rhythmbox-ubuntuone-music-store/trunk for something allowing me to change the privacy of a branch. It says "this branch is private", but doesn't give me a way to change it afaict?
[21:51] <lifeless> look for a yellow /
[21:51] <mars> lifeless, except that the inability to get lp:myproject to work leaves the members of our own development team feeling defeated and dumb :/
[21:51] <lifeless> mars: there is a bug open to add an API call to resolve the same stuff, and then bzr could use that; some problems are that: LP APIS are terribly slow, until recently there wasn't an anonymous provider which we'd need for un-logged-in-folk.
[21:52] <aquarius> there isn't a yellow exclamation icon next to "this branch is private". "Change branch details" doesn't have anything about privacy in it
[21:52] <lifeless> thumper: ^
[21:54] <mars> aquarius, I can confirm that, looking at my branch's details page.  There is no obvious privacy setting, unless it is:  "Keep branch confidential"?
[21:55]  * mars tries
[21:55] <mars> yep, that was it
[21:55] <lifeless> \o/ for using different terms to describe the same thing.
[21:55] <mars> usability bug: the setting to change "privacy" does not contain the word "privacy" within it, thus it is easily overlooked
[21:55] <lifeless> please file a bug
[21:56] <mars> will do
[21:56] <mars> aquarius, ^ you should have the "Keep branch confidential" setting?
[21:57] <aquarius> mars, where? I don't seem to have that
[21:58] <lifeless> aquarius: you might need to check the project privacy policy in that case (and if it is the problem file another bug that there wasn't a hint that this was the issue on the branch page)
[21:58] <mars> aquarius, visit the branch page, click "Change branch details" on the mid-right, on the settings page there is a "Keep branch confidential" checkbox, third setting down
[21:59] <mars> between the settings for "Name" and "Description"
[21:59] <aquarius> mars, not for me. on https://code.edge.launchpad.net/~sil/rhythmbox-ubuntuone-music-store/trunk/+edit I've got Owner, Name, Description, and Status.
[21:59]  * mars defers to lifeless
[22:01] <mars> and make some tea while I wait for the deferrable to process
[22:01] <aquarius> I can't find anything about project privacy, either
[22:01] <aquarius> (and the project can't be *that* private, a random dide filed an Answers question about it a few days ago, so it's not invisible or anything)
[22:01]  * aquarius is baffled
[22:02] <lifeless> aquarius: code.lp.net/projectname
[22:02] <lifeless> has a control for controlling branch privacy policies
[22:03] <aquarius> aha, "New branches you create for The Ubuntu Music Store Rhythmbox plugin are private initially."
[22:03] <aquarius> although there doesn't seem to be any obvious way of changing that
[22:03] <lifeless> right, but you need to edit it, because  Ithink you may have it set to 'can not be made public'
[22:04] <aquarius> I'm happy to edit it if I can find out how :)
[22:11] <aquarius> OK, I give in. Can't find where to change the privacy settings for new branches created for a project. Help? :)
[22:12] <lifeless> thumper: ^ ^
[22:16] <thumper> aquarius: the initial privacy setting is defined through a policy that only LP admins can set
[22:17] <aquarius> thumper, oh. hm. Is the initial privacy setting what's now stopping me from making my branch be aliased as lp:projectname?
[22:18] <thumper> aquarius: is the branch public or private?
[22:18] <thumper> aquarius: which branch?
[22:18] <aquarius> thumper, I don't know, and https://code.edge.launchpad.net/~sil/rhythmbox-ubuntuone-music-store/trunk, respectively
[22:19] <thumper> aquarius: yes it is private
[22:19] <lifeless> thumper: he wants to public it
[22:19] <thumper> aquarius: as defined by the "this branch is private" on the top right
[22:19] <lifeless> thumper: he can't find a button to do so, even looking where mars could see said button on his private brnach
[22:19] <aquarius> thumper, ah, yes, I did know that, sorry :)
[22:19] <thumper> aquarius: it should be in the +edit
[22:20] <thumper> aquarius: do you want to make the branch public?
[22:20] <lifeless> aquarius: screen shot time
[22:20] <aquarius> thumper, it isn't: mars had a "Keep branch confidential" setting in edit, and I do not
[22:20] <thumper> aquarius: then the privacy policy says you can't have public branches :)
[22:20] <aquarius> thumper, I want to make the branch be lp:rhythmbox-ubuntuone-music-store. If that entails making it public, that's fine :)
[22:21] <thumper> aquarius: the short name only works for public branches
[22:21] <aquarius> thumper, cool. The code's going into lucid in the next day or so, so I'm more than happy to be public. Do I need to get an admin to flip a switch somewhere on the project?
[22:22] <lifeless> so, who can change this. admins? spm: spmdo time.
[22:26] <mars> someone should rethink that "Everything is forced to be private" switch.  Which is more common: accidentally making my branch public, or deliberately making my branch public?
[22:27] <lifeless> mars: well I bet it was a simple misclick or some-such by the setter-uppoer
[22:27] <lifeless> Also I think that the privacy team owner should be able to fiddle that setting *after* an admin puts them as a privacy team for the project
[22:27] <aquarius> ah, I may well have deliberately made the project private, at least initially
[22:28] <lifeless> no need for admins after the iniitial setup
[22:28] <mars> lifeless, true, but I still think the entire idea underpinning the setting is flawed.
[22:28] <aquarius> because I was trying to stop people using the rhythmbox plugin to use the Ubuntu One Music Store before all the server side stuff was ready, because that would have led to a million bug reports saying "I have paid for some music and I can't download it". :)
[22:28] <mars> I bet in the history of LP there are zero instances where that setting has saved us trouble, and at least one instance where it has caused it :)
[22:29] <mars> aquarius, :)
[22:29] <lifeless> file bugs ;)
[22:30] <mars> lifeless, the challenge for me is presenting the case for a feature's removal.  I feel uncomfortable making the case on logic alone (as I did a moment ago)
[22:30] <aquarius> so, I need an admin, yes? is that spm? bac?
[22:31] <mars> lifeless, I feel my case should be backed by data, and data is time consuming and troublesome to collect.
[22:31] <mars> aquarius, yes, you need a LOSA
[22:32] <lifeless> aquarius: spm Chex mbarnett at this time I imagine
[22:32] <mars> aquarius, and we are waiting for one to appear
[22:32] <lifeless> mars: A bug is a conversation; you shouldn't wait to start it until you have proof, because other people may have data to help, or other points of view.
[22:32] <lifeless> mars: collaborate!
[22:33]  * mbarnett just me right now.
[22:33] <mars> lifeless, true.
[22:33] <lifeless> mbarnett: can you toggle the bit for aquarius please? his branch privacy setting won't let him release the code to public ;)
[22:34] <mbarnett> lifeless: i believe so, let me give it a go.
[22:37] <mbarnett> aquarius: there is no interface tool for that, have to set the bit on the db itself.  give me a moment and i will remove the private bit off of that branch for you.
[22:38] <aquarius> mbarnett, can you make it so that new branches created in that project are by-default public, too?
[22:38] <lifeless> mneptok: there is an interface
[22:38] <lifeless> bahh
[22:38] <mbarnett> aquarius: i should be able to, yes
[22:38] <lifeless> mbarnett: there is an interface
[22:39] <lifeless> mbarnett: in the branch polilcy area
[22:39] <lifeless> mbarnett: you need to change the *project-wide* policy setting from 'private only' to 'private by default' (or whatever aquarius wants).
[22:40] <lifeless> mbarnett: after doing that, aquarius can change his branch from private to public himself.
[22:40] <aquarius> it can all be entirely public
[22:43] <mbarnett> lifeless: ah, interesting.  i was doing it backwards.. i set that branch to public first.   That is good to konw, thanks.
[22:45] <lifeless> mbarnett: right, so the policy is able to say 'do not permit public at all', which was the problem
[22:47] <mbarnett> lifeless: right.  the difference between "private" and "private only"
[22:48] <mbarnett> aquarius: your branch is now public and new branches will be public by default.
[22:48] <aquarius> sweet, and lp:rhythmbox-ubuntuone-music-store now works. mbarnett, lifeless, thanks!
[22:48] <mbarnett> aquarius: welcome
[23:02] <thumper> aquarius: that is still a long project name :)
[23:02] <thumper> aquarius: could abbreviate to lp:rums :)
[23:02] <thumper> if you renamed the project :)
[23:02] <lifeless> not really much point in 'short urls' when you do that to us
[23:06] <aquarius> yeah. In retrospect, I probably shouldn't have done that. But I despise clever-clever names for things, especially something like the RB plugin which has no independent existence. This way, it's googleable. "rums" isn't :)
[23:09] <lifeless> well
[23:09] <lifeless> why is it a separate project if it has no independent existence?
[23:11] <aquarius> lifeless, because it's split into (a) an embeddable gtk widget that displays the music store, and (b) a rhythmbox plugin that embeds said widget.
[23:12] <aquarius> bundling the plugin in with the widget would be annoying for people who don't run rhythmbox and want to embed the widget in, say, Banshee
[23:24] <mneptok> lifeless: do not take my name in vain.
[23:24]  * mneptok awaits candy
[23:33] <lifeless> mneptok: vanity thy name is mneptok