=== yofel_ is now known as yofel
[00:49] <lifeless> idnar: you can setup dkim for app domains
[00:50] <idnar> lifeless: yeah, but I mean, it still has to be specifically whitelisted by Launchpad, right?
[00:50] <lifeless> idnar: or you can validate your app domain address as a separate 'send from' in gmail, and then it will be covered by the gmail dkim (because we trust gmails checking that you can receive mail at that address)
[00:50] <idnar> I have DKIM enabled for my apps domain, but it's just a one-user personal domain
[00:51] <lifeless> idnar: so there are two different things
[00:51] <lifeless> A) we support dkim.
[00:51] <lifeless> B) for some dkim sites we support a From: which is not from that site, if the site has still signed it.
[00:52] <idnar> oh, I see
[00:52] <wgrant> lifeless: But only signatures by gmail.com are trusted at the moment.
[00:53] <idnar> ah, I'm not going crazy then :)
[00:53] <lifeless> now, I'm not sure if for A we accept any site or just some, but the intent is to support any, or easily support many. For B yes, we do intend to have careful whitelisting proceedures (we need to validate that they only sign From addresses outside their site on a sensible basis)
[00:53] <lifeless> idnar: so if you want to be covered by A, its our *intent* to scale that quite a lot. For B, having your domain enabled for it is much less so :)
[00:54] <idnar> my mail is From: mithrandi@mithrandi.net and signed with d=mithrandi.net, so I think A) should cover it
[00:54] <lifeless> right
[00:55] <lifeless> poolie, who is not on, has been pushing this
[00:55] <idnar> (but currently it still won't work)
[00:55] <lifeless> I suggest filing a bug, and we can dig into whats up
[00:55] <lifeless> as wgrant says it may just be policy (so this is a good time for us to review how that works)
[00:55] <lifeless> the blog post that refers to 'by request' is talking about B specifically.
[00:55] <idnar> there's already https://answers.launchpad.net/launchpad/+question/146327
[00:56] <idnar> which references #643224
[00:56] <lifeless> righto
[00:57] <lifeless> idnar: so, short term: file a merge proposal adding your domain :)
[00:57] <lifeless> idnar: long term, I'll nag poolie :)
[01:01] <idnar> I don't know where mail/incoming.py is :P
[01:05] <lifeless> lp-branches/working$ find . -name 'incoming.py'
[01:05] <lifeless> ./lib/lp/services/mail/incoming.py
[01:45] <Noldorin> i registered a project group on LP some time ago... it no longer exists. can anyone help me please?
[01:53] <wgrant> Noldorin: What was it called?
[01:53] <Noldorin> wgrant, sorry, i made a mistake and got the name wrong. someone had taken my desired name previously
[01:54] <Noldorin> out of curiosity, can we now create project groups ourselves?
[01:54] <wgrant> You can't, no.
[01:54] <Noldorin> via the website interface
[01:54] <Noldorin> wgrant, oh :( any reason for that?
[01:54] <wgrant> They're somewhat deprecated.
[01:56] <wgrant> Noldorin: The project that previously occupied your desired name is gone?
[01:57] <Noldorin> wgrant, afraid not
[01:57] <Noldorin> wgrant, oh, deprecated in favour of what?
[01:57] <wgrant> Ah
[01:57] <wgrant> That's a very good question.
[01:58] <wgrant> No replacement has been devised.
[01:58] <Noldorin> i see.
[01:58] <wgrant> So project groups continue to exist while being hated by all.
[01:58] <Noldorin> may i ask why they were deprecated in that case?
[01:58] <Noldorin> evidently considered a design flaw of some sort...
[01:58] <Noldorin> structure flaw, rather
[01:59] <wgrant> They're not as useful as they could be. The suspicion is that being able to nest projects would improve things.
[01:59] <wgrant> Gives you multiple levels, allows you to file bugs on the group.
[01:59] <wgrant> Both things that have been desired.
[02:00] <wgrant> But it's not clear how this would best be implemented.
[02:02] <lifeless> the key thing is that project groups encode policy but most folk want to encode affiliation
[02:02] <lifeless> we will make new groups on request when folk have had this explained and have made an informed choice
[02:03] <wgrant> You say that encode policy, but I don't really think the current implementation knows what it intends to encode.
[02:03] <wgrant> s/that/they/
[02:03] <Noldorin> wgrant, ah, so eventually you may just expand the project framework to have a new type of projects that are simply composed of other projects?
[02:04] <Noldorin> and can thus be nested indefinitely
[02:04] <Noldorin> and have all the benefits
[02:04] <Noldorin> of normal projects
[02:04] <wgrant> That's one possibility.
[02:05] <lifeless> wgrant: not as a clear statement of intent no, but the design intent,a nd early implementation, and the beahviour of milestones and other things yes, they do
[02:09] <Noldorin> wgrant, i guess a major decision like that would go quite a way up to the top though
[02:09] <Noldorin> and probably won't be made short term
[02:20] <lifeless> we definitely want to eliminate project groups. whether they are replaced with one thing or many, and what that/they is/are is unknown yet
[02:20] <lifeless> for now, we only make them on request ;0
[02:20] <Noldorin> wgrant, i'm glad to know Canonical and the LP team is at least being forward-thinking. :-) slow perhaps...but then there are lots ofthings on thetask list
[02:21] <lifeless> Noldorin: now, all that said, what one did you want made, and whats it for ? :)
[02:21] <Noldorin> lifeless, oh, i had one from some time ago :-)
[02:21] <Noldorin> lifeless, thought i'd named it something, but sometime took my name so i had a more obscure name which i couldn't find heh
[02:21] <Noldorin> i can never seem to find the "list of all proejcts user X is involved in" on LP
[02:21] <Noldorin> involved in/maintains
[02:26] <lifeless> its not in your 'related software' portlet on launchpad.net/~/
[02:26] <lifeless> ?
[02:28] <Noldorin> lifeless, hmm?
[02:29] <Noldorin> lifeless, yeah. i never see that heh. could do with being on the main page insead/as well as "Latest memberships" really
[02:29] <Noldorin> hmm
[02:34] <Noldorin> not to midn
[02:34] <Noldorin> g'night golks
[02:34] <Noldorin> folks, even :-P
[02:34] <Noldorin> ^ it is late!
=== micahg_ is now known as micahg
[06:04] <Laibsch> what is the latest status of "nominate for release" in launchpad?  Is there actually a workflow behing this now?  Back in the days it used to be mostly ignored.
[06:04] <Laibsch> I'm interested in doing SRU work and wonder how I could easily see bugs that are fixed in #ubuntu+1 but affect an LTS.
=== Quintasan_ is now known as Quintasan
=== JanC_ is now known as JanC
=== EisNerd_ is now known as EisNerd
=== bulldog98_ is now known as bulldog98
[21:17] <michaelh1> Hi there.  Style question: I'm going to start a branch of crosstool-ng.  Should I set up a crosstool-ng project in Launchpad, set up a code import, then make my own project and branch off that?  If not, what should own the code import?
[21:56] <lifeless> michaelh1: are you starting a branch of, or a fork of ?
[21:56] <lifeless> michaelh1: if the former, you need just one project - crosstool-ng. If the latter, then having two projects makes sense.
[21:57] <michaelh1> A work area.  Most everything will go upstream, but we need somewhere for non-upstreamable stuff, tags, release noise, etc.  And somewhere to release from...
[21:57] <lifeless> I don't really know what work area implies ;)
[21:57] <lifeless> you say you are doing releases of the tool ?
[21:57] <lifeless> non-upstream releases ?
[21:59] <michaelh1> We'll use crosstool-ng to make binary builds of gcc-linaro.  I want others to be able to reproduce these, so I need to release the exact crosstool-ng and configuration that was used to make the binary
[21:59] <michaelh1> Think of crosstool-ng as a build script.
[22:00] <lifeless> its a grey area
[22:00] <lifeless> I think I'd start with a non-trunk *series* in the crosstool-ng project
[22:01] <lifeless> e.g. a series called trunk has the vcs import
[22:01] <lifeless> and a series called linaro has your releases of crosstool-ng
[22:02] <michaelh1> OK.  So launchpad.net/crosstool-ng doesn't exist yet.  I'll create it and set up the import into a series called 'trunk' and use that to seed the linaro series.
[22:03] <michaelh1> I feel a bit funny creating an import-only project for something I don't own...
[22:03] <lifeless> there is a setting when you register the project
[22:03] <lifeless> use it ;)
[22:03] <lifeless> ("I do not want to maintain this project")
[22:04] <michaelh1> ...and I should just ask the guy/inform him :)
[22:08] <Phantomas> Hello everyone! If I delete a PPA from a team, will it be possible to rename the team?
[23:24] <chrysn> wgrant: thanks, that really works :-). any reason this is not yet documented in https://help.launchpad.net/VcsImports?
[23:25] <wgrant> chrysn: It's brand new and we hope to have a better UI for it soon.
[23:25] <wgrant> Then we'll announce/document it.
[23:27] <chrysn> anyway, cool feature, works for me. (although i didn't do much bzr-side testing, just viewing in launchpad -- probably the typical behavior of people who use git and then do some stuff in lp.)
[23:28] <wgrant> Great!
[23:29] <chrysn> just waiting for my first recipe based on it to finish (local testing failed because of something fixed on the build servers; i've merged/built it often enough to be optimistic about it building)