[00:12] <infinity> stgraber: Or maybe you've disappeared, I'll just self-accept. :P
[00:12] <stgraber> infinity: just got back actually
[00:12] <infinity> Oh, hey.
[00:13] <robru> hey, if you guys are in a queue mood, don't accept ubuntu-app-launch just yet. want to get a new image built first ;-)
[00:13] <stgraber> infinity: accepted
[00:14] <infinity> stgraber: Ta.
[00:14] <stgraber> robru: don't worry, it's srcNEW AND a sync, it's way too much trouble to review for me to look into it ;)
[00:15] <robru> stgraber, haha, yeah, the last few srcNEWs I had took about a week each, so I wasn't worried at first. but now you guys are talking about the queues, thought maybe I was racing against the clock here ;-)
[07:09] <pete-woods> hi release folks, I see my HUD SRU upload was rejected, just wondered if anyone knew why, and what I should change?
[07:12] <RAOF> pete-woods: You (or your sponsor) should have got an email with the rejection message.
[07:13] <pete-woods> RAOF: okay, thanks, will try asking him
=== brendand_ is now known as brendand
[07:45] <sil2100> RAOF, pete-woods: we have no rejection message e-mails, the package has been sponsored by the CITrain so essentially the e-mail landed somewhere in some inbox that's inaccessible to anyone
[07:45] <RAOF> Urgh. Yay process.
[07:45] <pete-woods> :D
[07:46] <pete-woods> RAOF: does this mean you have been able to find out why?
[07:46] <pete-woods> or that I have to track down the "rejector"?
[07:46] <RAOF> You have to track down the rejector
[07:46] <sil2100> We will probably have to track down who rejected
[07:51] <infinity> sil2100: Or read the mailbox.
[07:51] <infinity> sil2100: If literally no one is reading that email, that's a massive failure in the citrain process.
[07:51] <sil2100> infinity: we would love to, but not sure who has access to it - I remember didrocks mentioning once that fginther has access to it
[07:51] <sil2100> infinity: right, we know
[07:52] <didrocks> hum? that completely untrue
[07:52] <didrocks> as now the sponsor is the guy pressing the publish button, if it was rejected by an archive admin/SRU team member, he will receive the email
[07:52] <didrocks> or launchpad is buggy otherwise
[07:52] <didrocks> but we made the change for this.
[07:53] <infinity> Both should get the email, probably, but I'd have to refresh myself on the rules of how all that works.
[07:53] <didrocks> sil2100: please, we discussed about it and I did the change for that… Try to remember the discussions we are having
[07:53] <infinity> The bot definitely will get mail still, though, as it's the one doing the actual copy.
[07:54] <sil2100> didrocks: I didn't get any e-mail and never got one, so I thought it was something that hasn't been implemented in LP
[07:54] <didrocks> sil2100: we discussed it 2 weeks ago, on that same very channel, and you were in the discussion
[07:54] <sil2100> didrocks: yes, but it never worked for me, so I thought it wasn't ready
[07:55] <infinity> The copy may have pre-dated that change?
[07:56] <infinity> Oh, not likely, if it was the 0528 build I see in rejected.
[07:56] <sil2100> We made the copy yesterday
[07:57] <didrocks> so, seems to be more on the launchpad side than "a massive failure in the citrain process" as some people jumped into saying that too early
[07:57] <infinity> didrocks: I said that based on sil claiming no one reads the email. :P
[07:57] <sil2100> didrocks: right, but why no one has access to the bot e-mail anyway? Is there some security concerns?
[07:57] <infinity> (Using the ubuntu archive bot in general is problematic there, until we get the email going somewhere more useful than chiark, it's not citrain's fault, per se)
[07:58] <sil2100> (or at least no one from the landing people)
[07:58] <didrocks> sil2100: ask fginther, I'm not the one who created it
[07:58] <sil2100> didrocks: I'll ask him, maybe this can be sorted out somehow in the meantime
[07:58] <infinity> sil2100: There's a massive security concern in giving wide access to email for a bot that's a member of restricted groups, yes.
[07:58] <infinity> sil2100: Since being able to read its email means being able to reset its password.
[07:59] <infinity> And this isn't Francis's bot, the copy was made by ~ubuntu-archive-robot
[07:59] <sil2100> infinity: then maybe at least making an e-mail forward in case of rejections to some landing team members
[07:59] <didrocks> infinity: I guess he's talking about ~ps-jenkins
[07:59] <didrocks> not the archive admin one
[08:00] <infinity> didrocks: Right, we should definitely sort out who's getting mail and why. :P
[08:00] <didrocks> infinity: right, after the sprint, we discussed about a way with Colin, like:
[08:00] <infinity> And yes, some procmail rules on the archive robot to forward known-safe mail to a list would be helpful too.
[08:00] <didrocks> - changelog entry be "lander <lander email>"
[08:01] <didrocks> - sponsored field is the guy pushing the "publish" button
[08:01] <didrocks> so, from what I get, the lander will then get assurely the email, right?
[08:01] <infinity> Who is the "lander" in that context?
[08:02] <infinity> Anyhow, it might be more complicated than that at the LP level.  We'll have to look.  LP tries hard to not spam people without knowing it's mailing the right person.
[08:03] <infinity> (like, if you build a source package changed-by me, signed by you, I shouldn't get mail about it, as there's zero evidence I actually had anything to do with it other than you spoofing my email)
[08:03] <didrocks> infinity: the lander is the guy telling "I've done the testing, sorted out the MPs and take responsability for that landing"
[08:03] <didrocks> (most of the time, it's the tech lead of a team or the manager in the touch context)
[08:05] <didrocks> infinity: the "sponsored" at least should receive it IMHO (the extra field I'm using now in the copy context). We made the change for that, maybe it's falling into the rule you are describing?
[08:05] <pete-woods> so can anyone tell me who I should expect to have the email? mhr3 is the one who clicks the build button for me, but I don't know who in CI clicked the publish button
[08:05] <infinity> Yeah, we'll have to look into it when I'm not passing by a computer at 2am between bed and the washroom.
[08:07] <pete-woods> is there a log of who accepted / rejected stuff maybe?
[08:07] <infinity> pete-woods: If it was rejected yesterday, it was almost certainly stgraber, he was on a roll.
[08:09] <pete-woods> infinity: thanks, I guess I'll have to wait for Canada tz
[08:10] <infinity> didrocks: I'm not sure what the right answer actually is for who should get mailed, versus how we protect against backscatter.  This wasn't something we had to think about before bots started doing copies, as the "signer" was always the right answer.
[08:10] <infinity> didrocks: (And the "signer" is the only person you can guarantee actually was involved in the upload, and thus can't complain about being spammed)
[08:11] <didrocks> infinity: that's a fair question and something to consider for sure, indeed.
[08:11] <infinity> didrocks: But perhaps a compromise would be to allow people with archive permissions (as the ubuntu-archive robot has) to spoof signer with the sponsored-by field or something.
[08:11] <didrocks> yeah, we can "trust" more those special signers
[08:17] <infinity> We'd probably want a separate set-signer attribute, I guess, so all sponsored uploads by all AAs don't suddenly get incorrectly signed.
[08:17] <infinity> (ie: if I sponsor an upload, it should be signed by me)
[08:18] <infinity> wgrant: Can you have a ponder at backscroll and see what you make of it?
[08:18] <didrocks> yeah, just tell me if I need to change anything, but I guess the correct behavior is the correct one (+ eventually the change discussed with colin)
[08:20] <didrocks> sil2100: do you feel/want to implement (no rush) the "changelog entry ends with the first lander name and email instead of ps-jenkins"? It should be < 7 lines in cu2d?
[08:23] <sil2100> didrocks: sure :)
[08:34] <wgrant> infinity, didrocks: "with archive permissions"?
[08:35] <wgrant> I can create another archive and give myself permissions on that just fine.
[08:35] <infinity> wgrant: As in, AA permissions on the target archive.
[08:35] <infinity> wgrant: But good point, one could create a PPA and use that to spam people.
[08:36] <wgrant> We may just have to bite the bullet and stab people who abuse the field.
[08:36] <wgrant> But people really like abusing Launchpad features, and we can never win.
[08:36] <wgrant> We see a similar problem with Debian people.
[08:37] <wgrant> if we don't attribute them when their packages are copied into Ubuntu, they're all like "grrr why you steal my work without attribution ubuntu is evil die die"
[08:37] <infinity> wgrant: We've done so very well up until now at not mailing people we shouldn't be, would be a shame to break that.
[08:37] <wgrant> If we do, the other half are like "grrrrrrr i hate ubuntu, ubuntu must die die die, i don't participate in ubuntu""
[08:37] <wgrant> We sort of need some way for people to opt into attribution/spam from an archive/distro.
[08:37] <wgrant> But that's hard.
[08:38] <infinity> wgrant: But yeah, it would be hard to accidentally spoof the signer if it's a distinct field, so it could only suffer from intentional abuse, not accidents.
[08:38] <wgrant> That's true.
[08:38] <wgrant> Most of the abuse we've seen in the past has been Changed-By/Maintainer.
[08:38] <wgrant> So possibly accidental.
[08:40] <infinity> And there's no need for, say, copy-package or syncpackage to implement the feature, as if you're a human doing a sync/copy, you ARE the signer, full stop.
[08:41] <infinity> So, it's really a case of "people abusing it would have had to write their own API client to do so", rather than "Joe Developer may have screwed up".
[08:41] <wgrant> Yeah
[08:41] <infinity> That could be enough assurance for me that any abuse would just be a clear TOS no-no, plus pretty unlikely to happen anyway.
[08:41] <wgrant> Heh, you clearly don't have much experience with some of our special users.
[08:42] <infinity> Well, there are much easier ways to spam/annoy people with much more interesting emails than to go to effort to create upload backscatter intentionally.
[08:42]  * infinity shrugs.
[08:43] <infinity> I'm not sure I see a better way out of this, other than giving a bot super-amazing permissions to be even scarier than normal AAs.
[08:43] <infinity> Which seems like a poor design decision, not to mention a pain.
[08:44] <wgrant> Indeed.
[08:44] <wgrant> So, we have a few fields. We should define who should receive which emails in which circumstances.
[08:46] <infinity> Well, I'm not positive how it works currently, but my gut says it's always the signer who gets everything.
[08:47] <infinity> ie: the person who signed the .changes or initiated the sync (which is morally equivalent)
[08:47] <infinity> So, spoofing the signer perhaps implies that you're overwriting whatever field that is.  uploader?
[08:48] <infinity> Which then leads to the "hey, people pressing that button in CI really need to have upload rights to the package" argument before the DMB lynches us.
[08:48] <infinity> And also means that the queue items would no longer unhelpfully say "synced by Ubuntu Archive Robot", but instead say "synced by Joe B Developer".
[08:52] <infinity> And yes, that option would have to be restricted to people with AA rights on the target archive, cause otherwise any old person could spoof a package signed by anyone else, which seems just fundamentally wrong (again, ignoring that anyone could do this in a PPA, which makes it all fall apart a bit...)
[08:52] <infinity> Hrm.
[08:52]  * ogra_ would already be happy if it could automatically list packaging changes in the changelog, regardless who owns the change/upload in the end 
[08:53] <ogra_> since most of these people are upstreams, not packagers such info usually gets forgotten or never shows up
[08:53] <ogra_> and its a pain having to dig into the source just for that
[08:56] <infinity> wgrant: Maybe I'm overthinking the PPA impact.  My concern was audit trails if someone succesfully spoofs another uploader, but since this can't happen on a source upload, only a copy, the original will always be correct, if you trace far enough back.
[09:25] <cjwatson> infinity,didrocks: the work I did in LP was specifically to ensure that *errors* (that is, copies failed because internal explosion) went to the sponsor of the copy
[09:25] <cjwatson> there's very likely additional work needed to ensure that *notifications* (e.g. rejections) go to the sponsor
[09:29] <cjwatson> infinity: there's nothing about this in ~ubuntu-archive-robot's mailbox, FWIW
[09:29] <infinity> cjwatson: Neat.
[09:29] <cjwatson> if somebody wants to set up a target list and give me a set of procmail rules then I'll gladly install them
[09:36] <infinity> cjwatson: We probably should move it to using ubuntu-archive@ubuntu.com, and get IS to set up a real account for that in the procmailers group, instead of having mail from a key infrastructure piece hosted on chiark. :)
[09:36] <infinity> cjwatson: But not a ticket I feel like filing right now.  I'm going to try to sleep again.
[09:50] <sil2100> cjwatson: ah, thanks for the info!
=== doko_ is now known as doko
=== NCommand` is now known as NCommander
=== NCommander is now known as Guest10479
=== oSoMoN_ is now known as oSoMoN
[11:55] <zequence> infinity: I readded yesterdays commits, with a couple of fixes. Tested locally, and seemed to work.
[11:57] <zequence> cjwatson: infinity: I'd very much like to have a new ISO built for us. The changes in our seeds probably gives a hint. There are a few things I'm a little confused about, like "ship". I've looked in other flavor seeds without getting less confused, just noticing that different seeds are done differently.
[11:58] <zequence> The idea is we don't ship our multimedia metas on the smaller ISO (cd-live), so not ubuntustudio-audio, -video, -graphics, -publishing and -photography
[11:59] <zequence> Later, I'll create a plugin for ubiquity that allows one to install those over a network connection. So, this CD would be a sort of netinstall image for us.
[11:59] <zequence> ..but, with the possibility to do some simple testing - which is why we want a live CD
[12:00] <zequence> Anyway, I'd appreciate any help we could get on getting this to work. I've done as much as I can understand right now.
[12:00] <zequence> Hard to find good docs on this stuff, but may be I'm not looking in the right places
[12:08] <jpds> So, can someone figure out why ima-evm-utils is still in NEW after about a month now?
[12:09] <seb128> jpds, it's easy to figure out "nobody has free slot to review NEW"
[12:09] <jpds> seb128: Looks quite empty otherwise: https://launchpad.net/ubuntu/utopic/+queue
[12:10] <seb128> jpds, not so much got uploaded, and some review happen when there is pushing/things blocked
[12:10] <seb128> so I guess nobody nagged about ima-evm-utils/it didn't get flagged as blocking work
[12:10] <seb128> so didn't raise enough in the priority list to get worked on
=== psivaa is now known as psivaa-lunch
=== Guest10479 is now known as NCommander
=== NCommander is now known as Guest44676
=== Guest44676 is now known as ncommander
=== ncommander is now known as NCommander
[13:06] <ogra_> hmm, i see no valid reason why ubuntu-touch-meta, ubuntu-session and the rest of the ubuntu-app-launch landing are still stuck in -proposed
[13:08] <ogra_> seems all autopkgtests passed fine
[13:09] <cjwatson> ogra_: see my comment in #ubuntu-ci-eng
[13:09] <cjwatson> they need a manual hint but I wanted click to land first
[13:09] <cjwatson> manual hint just because the autohinter isn't smart enough to notice the relationship between the multiple source packages involved
[13:09] <ogra_> ah, thanks i didnt realted that to the silo number :)
[13:09] <ogra_> *relate
[13:09] <cjwatson> usually it manages it but sometimes it needs help
[13:11] <cjwatson> so I have the hint prepared but I'll wait for click to get through
=== psivaa-lunch is now known as psivaa
[13:28] <stgraber> infinity, pete-woods, sil2100: just replied in #ubuntu-ci-eng, I rejected due to a bunch of changes in there not having bug references. And yes, it's a massive fail if those rejection e-mails don't get to anyone...
[13:30] <pete-woods> stgraber: if I indent the bullet points will that count? I was just trying to describe the fix in more detail (as it got rejected for that last time)
[13:31] <cjwatson> The previous rejection wasn't because there wasn't enough detail, it was because the changelog literally didn't even slightly match the change
[13:31] <cjwatson> (And, indeed, contained no (relevant) bug references)
[13:31] <cjwatson> What we're doing is downloading the source package in question and debdiffing it against what's currently in trusty-updates
[13:33] <cjwatson> The change now at least seems to match up, which is better than before
[13:33] <cjwatson> But I expect stgraber has reviewed it a bit harder than my skim-read
[13:34] <cjwatson> Just wanted to clarify the reason for the *previous* rejection
[13:34] <pete-woods> cjwatson: the problem is I was told to make the diff against what had got released, not against what was in proposed
[13:34] <pete-woods> so that's why the original changelog looked like that
[13:35] <pete-woods> I'm just trying to satisfy everyone's requirements here
[13:35] <cjwatson> I think that's not really good practice unless you're actually discarding all the previous work and effectively rebranching from the version in trusty
[13:35] <cjwatson> Which would be pretty unusual
[13:35] <cjwatson> I don't know who told you to do that
[13:35] <stgraber> for anyone interested, the debdiff is: http://paste.ubuntu.com/7587535/
[13:35] <cjwatson> This way is definitely more like what the SRU team would normally expect
[13:37] <stgraber> I'm having an hard time matching the diff with the changelog which is usually a pretty bad sign...
[13:37] <cjwatson> I wasn't sure, would probably have gone off to check the bzr history if it had been me reviewing it
[13:39] <pete-woods> apart from the missing bug references, the changelog describe what's changed to me at least
[13:40] <pete-woods> I was just trying to describe what I did to prevent the crash introduced in the previous release
[13:40] <stgraber> I don't see where the changelog tells me why you dropped the pre-start of that upstart job or why it's needed
[13:40] <pete-woods> it was duplicated
[13:40] <pete-woods> I don't know how it happened
[13:40] <pete-woods> but yes, I should have mentioned that
[13:41] <pete-woods> I can even ditch that part of the change if that helps
[13:41] <pete-woods> it just looked crazy to me to have the section twice in there
[13:42] <pete-woods> somehow it never stopped the upstart job from working
[13:42] <stgraber> nah, dropping the duplicate section is fine and may save you some trouble later (should someone decide to change one of them) but it needs to be documented so people looking at the diff (which doesn't include the whole file knows what's going on there and goes to look a bit closer :))
[13:43] <stgraber> there's also that utopic changelog entry which looks a bit odd but that may have been caused by whatever script generates the changelog for you...
[13:44] <pete-woods> in terms of the other changes, is there a way to say that these 3 things all refer to the same LP bug?
[13:44] <stgraber> sure, put the same bug number for each of them
[13:44] <pete-woods> okay, cool
[13:44] <stgraber> or ident them below the first one so I know it's additional description and not separate chagnes
[13:44] <cjwatson> Or indenting is fine too
[13:44] <stgraber> *changes
[13:44] <stgraber> *indent
[13:45] <stgraber> (typing is hard this morning apparently...)
[13:45] <cjwatson>   * General description of change (LP: #nnnnnnn):
[13:45] <cjwatson>     - first part
[13:45] <cjwatson>     - second part
[13:45] <cjwatson> or whatever
[13:45] <pete-woods> okay, cool, I will use that format, thanks!
[13:55] <pete-woods> I figured out where the utopic stuff came from, looks like CI-train accidentally merged to the 14.04 branch instead of 14.10
[13:55] <pete-woods> or something along those lines
[13:55] <pete-woods> so next time won't have the utopic stuff
[13:57] <seb128> pete-woods, if you do a SRU/target trusty, you need to state it in the comments so whoever does the silo config targets the right serie
[13:57] <seb128> (not sure if that was your issue there)
[13:57] <pete-woods> seb128: yes, the problem was a manual upload to utopic had its changes merged into the trusty trunk
[13:57] <pete-woods> it wasn't my upload
[13:58] <pete-woods> indeed, it was not CI train at all
[13:59] <sil2100> pete-woods: maybe there was some configuration mis-happening during the failures we've been having
[14:00] <sil2100> pete-woods: ok, let's reconfigure the silo with your branch then and try re-publishing, double-checking all the targets
[14:00] <pete-woods> sil2100: cool, I have updated the proposed branch now, so hopefully we are good to go :)
[14:01] <sil2100> pete-woods: I see it targetting the right branch - was it targetting trunk before?
[14:02] <pete-woods> sil2100: I don't think it was CI train that went wrong
[14:02] <sil2100> pete-woods: ah, so what do you think is the case?
[14:03] <pete-woods> I think someone pushed manually after a manual upload
[14:03] <pete-woods> maybe I hadn't updated the series at this point, as I wasn't expecting any releases
[14:15] <sil2100> pete-woods: ok ;)
[14:16] <sil2100> pete-woods: so anyway, now is the lp:hud/14.04 branch clean (like only having trusty changes) and the fix branch ready?
[14:17] <pete-woods> sil2100: yes, just removed the mistaken changes about 30 minutes ago
[14:17] <sil2100> ACK
[14:18] <sil2100> Excellent
[14:18] <sil2100> Then just set the silo to ready once it's done and tested and I'll publish
[14:22] <pete-woods> sil2100: cool, thanks
[14:24] <rcj> stgraber,
[14:24] <rcj> All of the architectures built for libdumbnet, can it be moved to main this morning?
[14:24] <stgraber> rcj: it should already be in main
[14:24] <stgraber> rcj: yep, it is and has been since yesterday evening
[14:25] <rcj> stgraber, I was looking at the upload queue which only showed it in universe.  Lesson learned.  Thanks.
[14:26] <stgraber> rcj: " Missing build dependencies: libcunit1-dev "
[14:26] <stgraber> rcj: you said libdumbnet was the only one...
[14:29] <rcj> stgraber, I seriously thought it was... Link to the dep failure?
[14:29] <stgraber> rcj: https://launchpadlibrarian.net/176896809/buildlog_ubuntu-precise-i386.open-vm-tools-lts-trusty_2%3A9.4.0-1280544-5ubuntu6~precise1_MANUALDEPWAIT.txt.gz
[14:43] <rcj> stgraber, cunit moved to main in Saucy.  Looking now...
[15:00] <shadeslayer> ScottK: ^^ 4.13.1 , can you plz accept
[15:03] <ScottK> shadeslayer: It's all in utopic already?
[15:04] <shadeslayer> ScottK: no, because we're merging there
[15:04] <shadeslayer> and I don't want to block
[15:04] <ScottK> ok
[15:13] <pete-woods> sil2100: the HUD packages have built now (except for PPC which seemed to have a crazy slow builder that timed out the tests)
[15:13] <sil2100> pete-woods: let me rebuild ppc then
[15:13] <pete-woods> thanks
[15:15] <cjwatson> sil2100: which builder was it on before?
[15:16] <sil2100> cjwatson: argh, I don't know, already retried - can I get the info somehow still?
[15:17] <cjwatson> sil2100: Not in the DB any more, but let me check the buildd-manager logs
[15:18] <cjwatson> ross - i.e. a ten-year-old xserve
[15:18] <cjwatson> unfortunately the two decent powerpc buildds are going to be busy for a few hours with webkitgtk and openjdk-7 respectively
=== chorrell is now known as chorrell-away
[15:18] <cjwatson> so I guess you could trust to luck
[15:19] <cjwatson> It's on adare now which is the same hardware generation
[15:36] <pete-woods> sil2100: seems like we don't even try running our tests under valgrind on ppc64, so maybe we should do the same on plain old ppc - it's a huge slowdown
[15:41] <Laney> Would somebody please promote grilo? https://bugs.launchpad.net/ubuntu/+source/grilo/+bug/1116098
[15:41] <cjwatson> That might just have been because valgrind didn't exist on ppc64el until April
[15:41] <cjwatson> But it'd be a reasonable workaround anyway
[15:42] <pete-woods> yeah, that's pretty much what I was thinking
[15:43] <pete-woods> although I guess ppc64 = fast modern server
[15:43] <pete-woods> not poor old xserve
[15:44] <cjwatson> Yes, I wouldn't expect ppc64el to have a speed problem with pretty much anything ever
[15:44] <cjwatson> sagari is pretty modern too and sulfur isn't terrible, so if all else fails we can reschedule on one of those once they're free
[15:44] <pete-woods> cool, thanks
[15:44] <cjwatson> (And hopefully we'll get powerpc converted to VMs on fast modern servers soon too)
[15:45] <pete-woods> this is definitely something I need to fix / workaround in the short term, though
[15:45] <pete-woods> as I can't come bothering you guys for every single HUD landing
[16:03] <pete-woods> woot, it built this time :)
[16:49] <stgraber> mdeslaur, jdstrand: do you have any problem with me promoting cunit to main in precise for open-vm-tools-lts-trusty? It's sadly not the exact same version as the one in trusty and I'm not sure we want to SRU the whole thing so that it's in sync. On the other hand, this is just a unit test framework, so seems low risk to me.
[16:50] <mdeslaur> stgraber: no objection from me
[16:51] <stgraber> ok, good. cunit doesn't have any universe build-dep so it seems safe to do the copy to updates + override trick
[16:51] <stgraber> doing that now then
[16:53] <rcj> stgraber, thank you for running this down.
[16:53] <stgraber> rcj: in 30min or so I should be able to override cunit into main which should fix the open-vm-tools-lts-trusty build and finally get us binaries
[16:54] <rcj> stgraber, that's excellent news
=== seb128_ is now known as seb128
[17:49] <stgraber> infinity: any idea why "./copy-package -d ubuntu -s precise --to-suite=precise-updates -b --auto-approve cunit" would get rejected?
[17:49] <stgraber> infinity: I get: cunit 2.1-0.dfsg-9 in quantal (binaries conflicting with the existing ones)
[17:51] <infinity> stgraber: That doesn't make much sense, given quantal has a different version...
[17:54] <infinity> stgraber: Can you bounce the reject?
[17:54] <infinity> stgraber: I can't find that string in LP anyhere...
[17:54] <infinity> Oh, cause I can't type.
[18:04] <infinity> stgraber: Oh.  Could be a goofy breakage because the original source was actually karmic, and the set of binary builds there doesn't match.  I know there's a bug/misfeature around that...
[18:05] <infinity> stgraber: Might be easiest to just upload a rebuild. :/
[18:07] <stgraber> infinity: yeah, I'll do that...
[18:13] <stgraber> infinity: ^ just did a local test build and things look good (was slightly worried as karmic => precise is quite a bit of time)
[20:35] <rbasak> cjwatson: this may be a really stupid question (which is why I haven't replied to the ML). It sounds like you're re-inventing the idea of a stable release, which we already have. So why is this different?
[20:35] <rbasak> If it's a relatively short term thing until things mature, does that mean that the need for this could disappear over time?
[20:36] <rbasak> I'm just curious - I am not a stakeholder at all here, but I wondered if I'm missing something, or if others will have that question.
[20:52] <stgraber> rbasak: see near the end of the e-mail, the plan is indeed for this to go away
[20:52] <stgraber> rbasak: the main problem is the date of the RTM being months before the 14.10 release date
[20:53] <stgraber> rbasak: we don't want to freeze the whole distro months ahead of schedule so forking the archive at whatever point cjwatson finds appropriate and then only landing the bits that are actually needed for the phone RTM image seems easier and less painful for people working on the rest of Ubuntu
[20:54] <ScottK> stgraber: Once this works once, how do things ever get back to alignment.
[20:56] <stgraber> ScottK: oh I absolutely agree with the feeling, some people will probably fight hard to keep the fork, however my hope is that it'll be sufficiently painful for them to keep stuff in sync that switching back to using the distro will be the obvious choice there.
[20:57] <ScottK> Only if there's some alignment of release schedules?
[20:59] <rbasak> stgraber: ah, OK. I interpreted that as the limited lifetime of individual RTM branches, as opposed to any limited lifetime of RTM branches altogether.
[20:59] <stgraber> I guess the plan is that once we've demonstrated that things can work and we have device out that we are in better position to dictate release dates for the OS and avoid that kind of things in the future
[21:06] <ScottK> Because cadence is important.
=== jhodapp is now known as jhodapp|afk