[00:14] <mtaylor> so we seem to be accepting intrepid uploads to PPAs, but we're not building them yet? 
[00:55] <thumper> poolie: if we were going to have different branch icons for 'series branch' / 'core dev branch' / 'other person branch' -- what should those icons be?
[00:55] <thumper> poolie: I was thinking different colour bazaar badges
[00:56] <thumper> poolie: obviously one is yellow, as it is now
[00:56] <thumper> poolie: what do you think about other colours?
[00:56] <thumper> poolie: or should we have something completely different?
[00:58] <poolie> thumper, hm
[00:59] <poolie> so series branches i think are already sufficiently distinguished by the text next to them
[00:59] <poolie> i suppose to start with we could also use text to say it's a dev team branch
[01:00] <poolie> i'm not sure this is a really high priority issue
[01:01] <poolie> are users finding that they have trouble distinguishing branches by core devs vs others?  are there products where this problem is clearly shown?
[01:04] <beuno> thumper, if I may, mayne the core-dev branch should have some sort of graphic that implies it's being worked on?
[01:05] <beuno> s/mayne/maybe
[01:07] <thumper> poolie: I was trying to help the situation where someone is hosting a project on launchpad, and there may be a number of branches associated with the project by the devs, then someone completely unrelated puts up a branch for the project.  Assuming that this branch is valid and appropriate it would be nice to show that the branch is by someone who is not yet a 'core dev'
[01:07] <thumper> beuno: what about branches by core devs that aren't being worked on?
[01:07] <thumper> poolie: it isn't a high priority issue
[01:08] <thumper> poolie: I'm just tring to make the listings more suitable and useful for project listings
[01:08] <thumper> poolie: while being friendly to the core devs of a particular project
[01:09] <beuno> thumper, well, why would a core-dev have a branch that is now in the series, and not be "in development"?   While I understand it *might* happen, I think the general case is that if it's not part of a release/trunk/series, then it's probably "work-in-progress"
[01:09] <thumper> beuno: what I was looking at was a different icon for a branch by a core dev that isn't associated with a series
[01:10] <thumper> beuno: as often branches by core devs are likely to be "more interesting" than those by others
[01:11] <beuno> thumper, right. Cutting-edge work in progress is very interesting for developers  :)    Anyway, I may be looking at it wrong, just thought I'd jump in
[01:12] <thumper> beuno: I don't mind you jumping in :-)
[01:14] <poolie> thumper: you could show a little spaceman to go with the rocket?
[01:14] <poolie> or a shield-type badge, meaning "official"
[01:14] <poolie> a crown?
[01:14] <thumper> halo?
[01:14] <poolie> halo could be good
[01:14] <thumper> c.f. blessed
[01:15] <poolie> tiny version of the project's logo
[01:15] <thumper> poolie: for series branch perhaps
[01:18] <thumper> poolie: I was really wanting this to be more similar to the blueprint icon colours, and the bug icon colours (showing importance)
[01:21] <poolie> ok
[01:21] <poolie> so maybe we need a generic "branch" icon that can be colored?
[01:21] <poolie> hm, though should it be colored according to ownership, or status?
[01:23] <wgrant> Status, or people will get confused with bugs.
[01:23] <wgrant> Er, wait, that's importance.
[01:23] <wgrant> Not status.
[01:30] <poolie> confused yet? :)
[01:30] <thumper> poolie: sorry, lost connectivity
[01:30] <poolie> hm maybe it would be nice if closed bugs had a cross-out drawn through them?
[01:30] <poolie> i don't think you missed much
[01:30] <poolie> 10:21 <poolie> so maybe we need a generic "branch" icon that can be colored?
[01:30] <poolie> 10:21 <poolie> hm, though should it be colored according to ownership, or status?
[01:30] <poolie> 10:23 <wgrant> Status, or people will get confused with bugs.
[01:30] <poolie> 10:23 <wgrant> Er, wait, that's importance.
[01:31] <thumper> people get confused no matter what we do
[01:32] <poolie> so seriously i think we should not worry about this yet
[01:32]  * thumper shrugs
[01:33] <poolie> i just tried clicking through some of the projects linked from the branch cloud and i never felt very confused about this
[01:34] <poolie> i realize i'm atypical
[01:34] <poolie> i think a halo would be totally fine, if you want to add it
[01:34] <poolie> https://code.edge.launchpad.net/~mathiaz/apport/ubuntu-mathiaz <-- great branding photo :)
[01:44] <gnomefreak> the vlc guys might beable to use that since it does remove the interfaces i will update my statements
[01:47] <gnomefreak> sei updaed it sorry its kind of late here atleast its been a veery long day i thought it was still on firefox-3 so lets see what vlc bug triager says im still gonna get the team to see if its reproducable. i updated everything on bug.
[01:47] <gnomefreak> oops
[07:56] <bca1> hi there
[07:58] <bca1> i'm a mentor for the GSoC 2008, and my student and I are evaluating hosting projects, for the moment we use code.google but we are really interesting in launchpad, we have only one question with no answer: does launchpad provide a kind of wiki place or something similar that we can use to display documentation/tutorials ?
[07:59] <jamesh> bca1: not at present
[08:00] <bca1> ok, so we need to setup an external website to present our project and give informations on how to use it
[08:01] <bca1> thanks for this quick answer
[10:48] <asabil> hi all
[10:48] <asabil> I have some troubles with the new launchpad ppa copy
[10:49] <asabil> I copied some source packages from gutsy to hardy
[10:49] <asabil> they apparently got built correctly
[10:49] <asabil> but they don't appear in the Packages file
[10:50] <asabil> http://ppa.launchpad.net/people-project/ubuntu/dists/hardy/main/binary-i386/
[10:51] <cprov> asabil: https://bugs.edge.launchpad.net/soyuz/+bug/227184
[10:53] <cprov> asabil: you have generated duplicated binaries (same name and version, but different contents). The archive files (the binaries previously generated in gutsy)  can't be modified.
[10:54] <cprov> asabil: I'm working in a fix that will make it clear that a mistake has happened while copying.
[10:56] <asabil> oh ok
[10:56] <asabil> so what would the copy feature be good for ?
[10:57] <cprov> asabil: to copy source & binaries from one suite to another, for instance.
[10:57] <asabil> I basically just want to publish the packages for both gutsy and hardy
[11:01] <emgent> cprov: if you have little bit time see #canonical-sysadmin
[11:01] <wgrant> asabil: Then check the 'Copy binaries' box.
[11:01] <asabil> what does the copy binaries do ?
[11:01] <asabil> copy the binaries ?
[11:01] <wgrant> Copies the binaries.
[11:02] <asabil> even if they are incompatible ?
[11:02] <wgrant> Yes.
[11:02] <asabil> the current UI is just confusing
[11:02] <wgrant> How?
[11:02] <wgrant> What could 'Copy binaries' mean other than ... copy the binaries?
[11:02] <emgent> SteveA: ping
[11:02] <asabil> would't it be possible to have a set of checkboxes with the various supported distros ?
[11:03] <wgrant> emgent: Don't ping random LP devs...
[11:03] <emgent> wgrant: SteveA is a lp leader
[11:03] <wgrant> He's not a Malone dev.
[11:05] <cprov> asabil: it would, but that's another bug, right ?  It's not related to the fact that you can't rebuild sources withing the same PPA.
[11:05] <asabil> I am asking about the use of the copy feature
[11:06] <SteveA> emgent: hi
[11:06] <asabil> how useful is it if copying from Gutsy to Hardy for example would systematically fail
[11:07] <wgrant> asabil: Why would it fail?
[11:07] <cprov> asabil: it wouldn't fail if you wait the gutsy binaries to be built and copy them too.
[11:08] <asabil> but I don't want to copy the binaries
[11:08] <wgrant> Why not>?
[11:08] <asabil> I want the source to be copied and Hardy binaries to be generated
[11:08] <wgrant> It will probably work.
[11:08] <wgrant> Hundreds of our binaries haven't changed since Warty.
[11:08] <wgrant> Most of them haven't changed since Gutsy.
[11:08] <asabil> I am sorry I cannot see the point
[11:09] <wgrant> Why do you want them rebuilt?
[11:09] <wgrant> Unless it is unlucky enough to depend on a library that has had a SONAME bump, the Gutsy binaries will work fine in Hardy.
[11:10] <SteveA> bigjools: hi
[11:10] <bigjools> SteveA: hi there
[11:10] <SteveA> emgent is having a problem with package sync requests.  would you be able to help him out?
[11:11] <bigjools> I can have a look
[11:11] <SteveA> thanks
[11:12] <bigjools> emgent: what's up?
[11:12] <emgent> seems lp problem
[11:13] <emgent> (11:57) ( Ng) emgent: well from our MTA logs it looks like your mail was delivered  fine, so we'll need  to check with the launchpad guys for what their code did with it
[11:13] <cprov> SteveA: package-sync-request == open bugs via email.
[11:13] <emgent> requestsync script send fine request but launchpad dont process it.
[11:13] <bigjools> emgent: I don't have any context, can you explain what the problem is please
[11:14] <SteveA> cprov: oh right, it's using the bug tracker as a queue of tickets
[11:14] <SteveA> in that case, it's one of the bugs guys
[11:14] <cprov> SteveA: exactly.
[11:14] <SteveA> BjornT: hi
[11:15] <emgent> bigjools: i use requestsync script and the script send fine mail, but launchpad dont process it.
[11:15] <BjornT> hi SteveA 
[11:16] <SteveA> hi BjornT.  emgent is having a problem with getting bugmail processed by launchpad, when sent via the requestsync script.
[11:16] <SteveA> he's been in touch with admins, who say the mail arrived with us.
[11:16] <SteveA> is there someone on your team who can look into it?
[11:19] <BjornT> SteveA: i could take a quick look at it
[11:19] <emgent> thanks
[11:19] <BjornT> emgent: can you give me a copy (including headers) of one of the mail you sent?
[11:20] <emgent> BjornT: the script sent mail, i can sey to you mail address: emgent@emanuele-gentili.com
[11:20] <emgent> it`s sympa Sync
[11:24] <BjornT> emgent: seeing a copy of a sent mail would help to debug it. also, if you give me the message-id of one of the mails, i could look into it more easily.
[11:25] <emgent> BjornT: you can ask to Ng (canonical syadmin) he saw my problem some moment ago.
[11:26] <emgent> BjornT: join #canonical-sysadmin
[11:35] <slytherin> Can I ask a question about PPA here?
[11:36] <wgrant> slytherin: This place is probably better than any.
[11:37] <cprov> slytherin: yes
[11:37] <wgrant> slytherin: Were there any builds created at all?
[11:38] <wgrant> I didn't think Intrepid had any PPA archs yet.
[11:38] <slytherin> wgrant: that is what I am not able to understand. When I built the package locally for hardy it worked. But since I didn't want to setup intrepid chroot I uploaded it to PPA
[11:38] <wgrant> https://edge.launchpad.net/ubuntu/+ppas seems to suggest that there are no Intrepid archs yet. cprov?
[11:39] <cprov> wgrant: yes, intrepid is not open for PPA yet.
[11:39] <wgrant> cprov: Shouldn't it be rejecting things?
[11:40] <wgrant> I've seen this asked quite a number of times now.
[11:40] <cprov> wgrant: yes, sort of, we were not expecting series to take to long for supporting PPAs.
[11:41] <wgrant> Is it the debootstrapping breakage holding it up?
[11:42] <cprov> wgrant: I remember of a bug opened for a similar problem (Architecture: sparc powerpc, for instance)
[11:42] <wgrant> That's quite different, though.
[11:44] <cprov> wgrant: no, it's not. they are all pointless source uploads, they can't be build in PPA context, so they should be rejected. 
[11:45] <wgrant> I guess...
[11:45] <cprov> wgrant: accepting the source upload just create false expectations, right?
[11:46] <wgrant> Perhaps so.
[11:46] <wgrant> Will primary reject if I upload something for m68k?
[11:46] <cprov> wgrant: currently not, but it should as well
[11:48] <wgrant> cprov: I suppose rejecting if there are no valid architectures can't cause anything to go horribly wrong. Seems a bit odd, but probably can't do anything nasty.
[11:49] <cprov> wgrant: it like if we say: "It requires, at least, one valid arch to get the source accepted"
[11:50] <cprov> something in that directions, 'powerpc m68K' would fail in PPA but work in primary archive
[11:53] <wgrant> Right, that's say.
[11:53] <wgrant> *sane
[12:08] <cprov> wgrant: the bug I mentioned was https://bugs.edge.launchpad.net/soyuz/+bug/173866
[14:51] <ushimitsudoki> I created my new project in launchpad, but I can't see where to turn on bug tracking?
[14:52] <beuno> ushimitsudoki, you should have "Bugs are tracked in" on "Bugs are tracked: 
[14:53] <beuno> argh, that came out wrong
[14:53] <beuno> under "Change details"
[14:53] <beuno> you can select where bugs are tracked
[14:53] <beuno> Launchpad is one of those options  :)
[14:53] <intellectronica> ushimitsudoki: https://launchpad.net/projectname/+edit
[14:54] <ushimitsudoki> bueno: ah-ha! thanks much!
[14:55] <ushimitsudoki> now back to coding! :)
[16:33] <emgent> -.-
[16:36] <fta2> when will the ppa builders start to build for intrepid ?
[16:38] <fta2> and will they process the packages already pushed (accepted but never built) ?
[16:47] <cprov-lunch> fta2: yes, when intrepid PPA gets enabled it will catchup on accepted sources.
[16:48] <Hobbsee> cprov-lunch: when will that be?
[16:48] <cprov-lunch> Hobbsee: I don't know.
[18:03] <AnAnt> Hello, is launchpad only for Ubuntu related projects ?
[18:05] <gmb> AnAnt: No, it's for any open-source project :)
[18:05] <AnAnt> gmb: ok, thanks
[18:07] <AnAnt> gmb: is LPPL considered open-source according to LP?
[18:07] <gmb> AnAnt: LPPL as in LaTeX Project Public License?
[18:20] <gmb> AnAnt: Sorry, I got disconnected. Did you see any of what I said about the LPPL?
[18:20] <AnAnt> gmb: nope
[18:20] <gmb> AnAnt: Okay.
[18:20] <gmb> So, I said:
[18:20] <gmb> AnAnt: LPPL as in LaTeX Project Public License?
[18:20] <AnAnt> gmb: yeah
[18:20] <gmb> AnAnt: I see no reason why not. When you create your project you can choose which license it comes under. Simply choose Other/Open Source if your license isn't listed and then give details of the license in the "Description of Addtional License" text area.
[18:21] <AnAnt> gmb: well, sourceforge only approves project under OSI approved licenses ! that's why I ask
[18:21] <AnAnt> gmb: AFAIK, LPPL is FSF approved but not OSI approved
[18:21] <gmb> AnAnt: We're not SF ;).
[18:22] <gmb> AnAnt: If it's FSF approved then I think it's fair to say that you're okay to use it.
[18:22] <gmb> If there are any issues with the license we'll let you know.
[18:22] <AnAnt> thanks
[18:22] <gmb> But I'm 99% certain you'll be okay.
[18:52] <Glich> hello?
[18:56] <Glich> hello?
[18:56] <andrea-bs> Glich: yes?
[18:57] <Glich> hi, I was just wondering, with the translator service how do I suggest that a voting system can be applied to the suggestions?
[19:03] <Glich> Only I think that it would increase the speed of translating.
[19:05] <andrea-bs> Glich: just file a new bug in rosetta: https://launchpad.net/rosetta/+filebug :)
[19:06] <Glich> bugs are the same as suggestions?
[19:08] <andrea-bs> Glich: bugs are generally issues, but they can be also suggestions (Wishlist bugs)
[19:09] <Glich> ah! thanks!
[19:09] <andrea-bs> you're welcome :)
[19:09] <Glich> :D
[21:01] <_polto_> hello all
[21:03] <_polto_> how should I name my PPA package to be overwrite standard mplayer package ? the actual Mplayer is mplayer - 2:1.0~rc2-0ubuntu13 so should I name it mplayer - 2:1.0~rc2-0ubuntu13~ppa1 ? It does not work this way, the normal packet is reinstalled if I do an apt-get upgrade.
[21:04] <_polto_> any ideas pls ?
[21:10] <stdin> _polto_: increment the last number of the normal release, then add you ~ppa1 extension
[21:10] <stdin> so 2:1.0~rc2-0ubuntu14~ppa1
[21:10] <stdin> then when 2:1.0~rc2-0ubuntu14 or higher comes out, it'll override yours
[21:12] <_polto_> ok thanks !
[21:41] <stdin> recently I've been getting build failure emails from PPAs when I didn't upload the package, I've filed a bug report about it: bug #227474
[21:54] <fta> rothera (i386) NOT OK : timed out (AUTO), again
[21:54] <fta> it's not helping clearing out the auto-sync backlog :P
[23:54] <gnomefreak> emma: can you add the concerns you had to the talk page or ML as he only talks about the experation date