| === yofel_ is now known as yofel | ||
| lifeless | idnar: you can setup dkim for app domains | 00:49 |
|---|---|---|
| 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:50 |
| 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:51 |
| idnar | oh, I see | 00:52 |
| wgrant | lifeless: But only signatures by gmail.com are trusted at the moment. | 00:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| idnar | which references #643224 | 00:56 |
| lifeless | righto | 00:56 |
| lifeless | idnar: so, short term: file a merge proposal adding your domain :) | 00:57 |
| lifeless | idnar: long term, I'll nag poolie :) | 00:57 |
| idnar | I don't know where mail/incoming.py is :P | 01:01 |
| lifeless | lp-branches/working$ find . -name 'incoming.py' | 01:05 |
| lifeless | ./lib/lp/services/mail/incoming.py | 01:05 |
| Noldorin | i registered a project group on LP some time ago... it no longer exists. can anyone help me please? | 01:45 |
| 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:53 |
| 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:54 |
| wgrant | Noldorin: The project that previously occupied your desired name is gone? | 01:56 |
| 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:57 |
| 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:58 |
| 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. | 01:59 |
| wgrant | But it's not clear how this would best be implemented. | 02:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:09 |
| 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:20 |
| 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:21 |
| lifeless | its not in your 'related software' portlet on launchpad.net/~/ | 02:26 |
| lifeless | ? | 02:26 |
| Noldorin | lifeless, hmm? | 02:28 |
| 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:29 |
| Noldorin | not to midn | 02:34 |
| Noldorin | g'night golks | 02:34 |
| Noldorin | folks, even :-P | 02:34 |
| Noldorin | ^ it is late! | 02:34 |
| === micahg_ is now known as micahg | ||
| 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. | 06:04 |
| === Quintasan_ is now known as Quintasan | ||
| === JanC_ is now known as JanC | ||
| === EisNerd_ is now known as EisNerd | ||
| === bulldog98_ is now known as bulldog98 | ||
| 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:17 |
| 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:56 |
| 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:57 |
| 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. | 21:59 |
| lifeless | its a grey area | 22:00 |
| lifeless | I think I'd start with a non-trunk *series* in the crosstool-ng project | 22:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| michaelh1 | ...and I should just ask the guy/inform him :) | 22:04 |
| Phantomas | Hello everyone! If I delete a PPA from a team, will it be possible to rename the team? | 22:08 |
| chrysn | wgrant: thanks, that really works :-). any reason this is not yet documented in https://help.launchpad.net/VcsImports? | 23:24 |
| 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:25 |
| 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:27 |
| wgrant | Great! | 23:28 |
| 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) | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!