[06:32] <dholbach> good morning
[09:59] <matti> Morning folks.
[10:00] <thekorn> hey matti
[10:00] <matti> :)
[15:06] <bddebian> Boo
[16:32] <micahg> bdmurray: what's the policy with setting upstream links for pacakges in ubuntu?
[16:33] <micahg> on the package overview page
[16:33] <bdmurray> micahg: ask jcastro to do it
[16:34] <micahg> I can't do it?
[16:34] <micahg> I was just wondering if it breaks anything or it just helps for people clicking the upstream bug link
[16:35] <micahg> if I can't do it, I should file an LP bug since it offers me the option :)
[16:36] <bdmurray> You can do it its just a lengthy process that jcastro is most familiar with.
[16:36] <micahg> I was looking at this page: https://edge.launchpad.net/ubuntu/karmic/+source/firefox-3.5/+edit-packaging
[16:37] <bdmurray> what bug number were you to get to that url?
[16:37] <bdmurray> I wouldn't have expected the karmic bit in the url
[16:37] <micahg> no bug number
[16:38] <micahg> I went to https://edge.launchpad.net/ubuntu//+source/firefox-3.5
[16:38] <jcastro> micahg: I think anyone can set it
[16:38] <micahg> and clicked set upstream link
[16:38] <micahg> jcastro: could it break anything
[16:38] <micahg> or it just shows a default project for upstreaming?
[16:39] <jcastro> it just shows the default project
[16:39] <jcastro> micahg: though I check with the team first
[16:39] <micahg> ok
[16:39] <micahg> I'll talk to asac
[16:39] <micahg> thanks
[16:39] <jcastro> micahg: probably run it past asac/fta or someone from mozillateam
[16:39] <jcastro> ok
[16:41] <hggdh> this is actually a good question -- I found, some days ago, an upstream for a package (sigh don't remember which anymore), but setting the upstream link got me confused, and I decided *not* do to it
[16:43] <qense> it's indeed a bit confusing
[16:44] <qense> I always end up at a page that seems to be about adding the link to the branch of the active release series.
[16:47] <hggdh> indeed. and there I stopped :-( jcastro, what should be done?
[16:48] <jcastro> hggdh: I don't know, it's dumb, it asks you for series and all this stupid crap
[16:48] <jcastro> hggdh: the major projects have it set so unless I need to I don't mess with it
[16:49] <hggdh> so we leave it as is (no upstream)?
[16:50] <bdmurray> well, then you can't have a bug watch which isn't good
[16:50] <qense> can't you choose a project when adding an upstream task to a bug in a package that hasn't got a default upstream bug tracker set?
[16:54] <hggdh> bdmurray: yes, this is my point: we will not know who to contact (except for packages imported from Debian, I guess)
[16:55] <bdmurray> well, debian is different since you are choosing also affects distribution
[16:56] <bdmurray> So I think documenting the process for setting up the upstream link would be good
[16:57] <hggdh> +1. I have, immediately, LIBPST -- we went out of Debian (no support for Outlook 2003+) into a different fork, and I cannot see how to set it
[16:58] <hggdh> not counting all the others that have bugs opened, but no real upstream. Granted, a lot go via Debian, but a lot also have had no action in a while.
[17:04] <bdmurray> hggdh: see https://staging.launchpad.net/libpst and https://staging.launchpad.net/ubuntu/karmic/+source/libpst
[17:05] <bdmurray> hggdh: and https://bugs.staging.launchpad.net/ubuntu/+source/libpst/+bug/429118 and choose also affects project on that
[17:05] <ubot4> Launchpad bug 429118 in hplip "no scanner detected" [Undecided,New]
[17:07] <hggdh> looking
[17:13] <hggdh> bdmurray: now how do we add in the upstream link -- the real location of the source, and maintainers?
[17:14] <bdmurray> hggdh: I think you edit the libpst project with that information
[17:15] <hggdh> bdmurray: I cannot see where... I am expecting a place where I can add a link (like www.five-ten-sg.com/libpst)
[17:16] <bdmurray> hggdh: can you see https://staging.launchpad.net/libpst/+edit?
[17:16] <hggdh> not allowed here...
[17:16] <bdmurray> ah, so it is probably because I created the project
[17:17] <hggdh> so this also may be a reason why we cannot find where to add this data
[17:18] <bdmurray> try again I made you the maintainer
[17:18] <hggdh> k
[17:18] <bdmurray> anyway the way the process works is create project, link to upstream project
[17:18] <hggdh> k
[17:18] <hggdh> ok
[17:18] <bdmurray> link using the form micahg showed earlier
[17:18] <bdmurray> and maybe make bugcontrol the maintainer(?)
[17:19] <hggdh> I think this may be a good idea; either just bug-control, or ubuntu members (depends on how critical this data is considered)
[17:20] <bdmurray> I'd say bug control with a plan of changing it to bugsquad after making that a restricted team
[17:20] <hggdh> or a special group created for this type of work?
[17:20] <bdmurray> Unfortunately, I don't have time at the moment to document the process
[17:21] <hggdh> well, we cannot document until we know who will have access to it ;-)
[17:22] <hggdh> bdmurray: were you thinking of something like "setting up and updating upstream links"?
[17:26] <bdmurray> hggdh: Yes, that sounds good.
[17:26] <bdmurray> jcastro: Are you usually the 'maintainer' of the upstream project?
[17:27] <jcastro> no
[17:27] <bdmurray> who do you make that then?
[17:34] <matti> :)
[18:58] <debfx> lp doesn't recognize http://bugs.gentoo.org/... as a Gentoo Linux bug tracker url :(
[19:00] <debfx> ah http://bugs.gentoo.org/show_bug.cgi?id= works
[19:00] <debfx> still, both urls should work
[19:05] <hggdh> debfx: why should bugs.gentoo.org work? It is not a bug link, it is the home page.
[19:06] <debfx> hggdh: for example http://bugs.gentoo.org/270372
[19:07] <hggdh> oh
[19:07] <hggdh> heh
[19:07] <hggdh> then yes, indeed. Can you please search for an open bug on launchpad itself on that, and open one if you do not find a match?
[19:19] <jcastro> bdmurray: sorry I was off doing something else
[19:19] <jcastro> bdmurray: which specific field?
[19:20] <debfx> hggdh: yeah I found an open bug
[19:20] <bdmurray> jcastro: the maintainer for an upstream project
[19:21] <hggdh> debfx: may I suggest you add a comment about when it is going to be fixed? ;-)
[19:22] <jcastro> bdmurray: you mean when trying to link to an upstream bug and lp doesn't know what to do and you have to fill out a series and all that?
[19:23] <qense> the maintainer of a newly created project that's used for linking to a bug tracker upstream, iirc
[19:25] <kees> bdmurray: do you have a "packages without apport hooks" report anywhere?
[19:25] <bdmurray> jcastro: yes, you create the upstream project and by default you become the maintainer for that project.  Do you change that?
[19:25] <jcastro> oh I see what you mean
[19:25] <jcastro> no, though perhaps I should make it owned by Registry by default
[19:26] <jcastro> I haven't had to create a new one in a long time
[19:26] <jcastro> and the last few times it was because an existing project split and we needed it to be a project in order to link bugs
[19:26] <bdmurray> jcastro: I was thinking ubuntu-bug control might be good
[19:26] <jcastro> ok
[19:26] <jcastro> as I see them I'll move em over
[19:27] <jcastro> bdmurray: for bonus points, I filed a bug about making it so you can link bugs without having to care about wether the project or not exists in lp
[19:27] <jcastro> which I think would be much easier
[19:29] <hggdh> (meanwhile... I added the libpst project with upstream contact, and set the owner to bug-control)
[20:00] <micahg> bdmurray: can project admins have +filebug?no-redirect by default?
[20:00] <micahg> or rather can -control members have it?
[20:01] <bdmurray> micahg: why shouldn't we too use ubuntu-bug?
[20:02] <qense> is the change already on edge?
[20:02] <bdmurray> No, likely tomorrow
[20:02] <micahg> bdmurray: for the times when it's unnecessary
[20:03] <micahg> otherwise, we would use it
[20:03] <bdmurray> micahg: well, a hand crafted url can be used for those times.  I think they are the exception.
[20:05] <bdmurray> kees: the shorter report would be packages with apport hooks
[20:06] <micahg> bdmurray: how do people submit needs-packaging requests?
[20:06] <bdmurray> with ?no-redirect but please don't link to that directly
[20:07] <micahg> bdmurray: ok, how do normal users submit needs-packaging requests?
[20:08] <bdmurray> they'll need to use +file-bug?no-redirect
[20:08] <micahg> right, so is that explained on the reporting bugs page?
[20:08] <qense> why not write an apport hook for that? Prefilled forms would make the life of the MOTUs a lot easier.
[20:09] <micahg> qense: prefill with what?
[20:09] <bdmurray> micahg: no, needs-packaging bug reports are a small percentage of the bug reports we receive
[20:10] <bdmurray> additionally, the vast majority of them are still open
[20:10] <qense> you could present the user with a form asking all information required for all need packaging, FreezeException, SRUs, etc bugs
[20:10] <qense> if you don't provide all information they won't be submitted
[20:11] <micahg> ok, so when a user comes in here and asks how to request a new package, what do I say?
[20:11] <micahg> do I give them the URL hack?
[20:12] <qense> yes
[20:12] <qense> isn't there a wiki page explaining the procedure?
[20:12] <micahg> yes, it lists the info needed in the bug
[20:12] <bdmurray> Tell them we aren't adding any new pacakges. ;-)
[20:14] <bdmurray> Anyway, those users will most likely be on production not staging so it won't matter at the moment.
[20:15] <kees> bdmurray: true, that could work too.  I just wanted to compare it against https://bugs.edge.launchpad.net/~ubuntu-security/+packagebugs
[20:17] <bdmurray> kees: https://wiki.ubuntu.com/Apport/PackageHooks
[20:18] <bdmurray> kees: compare it for?
[20:22] <kees> bdmurray: just to see what the security team is watching for bugs, and which packages don't yet have apport hooks
[20:23] <bdmurray> micahg: we could update the wiki page at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[20:27] <bdmurray> micahg: okay, I did that
[20:29] <qense> bdmurray: is there a way of letting the ui in an apport hook notice the reported: e.g. ask to connect the device before continuing by clicking on OK?
[20:31] <bdmurray> qense: I'm not certain I'd look at the storage symptom though - just briefly looking at it it seems that it uses a sleep statement.
[20:32] <qense> thanks for the tip. I'm now reading the code for that function in /usr/share/pyshared/apport/ui.py
[20:44] <micahg> thanks bdmurray, I bookmarked for reference
[21:59] <hjmf> please take a look to bug #430272
[21:59] <ubot4> Launchpad bug 430272 in ubuntu "karmic boot hung after /scripts/init-bottom" [Undecided,Confirmed] https://launchpad.net/bugs/430272
[22:01] <bdmurray> hjmf: as I understand it that is being actively worked on
[22:05] <hjmf> bdmurray: k
[23:28] <david3> Is there a fix posted somewhere for the Karmic GDM freeze? Using Sep 15 build btw.
[23:50] <VIRTUALMAN> hi
[23:51] <VIRTUALMAN> i have a pb with Nautilus....
[23:51] <VIRTUALMAN> "Could not display "computer:"
[23:51] <VIRTUALMAN> Nautilus cannot handle "computer" locations.
[23:51] <VIRTUALMAN> help plz:)