--- /dev/null
+18:00:01 <dondelelcaro> #startmeeting
+18:00:01 <MeetBot> Meeting started Thu Dec 4 18:00:01 2014 UTC. The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
+18:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+18:00:07 <dondelelcaro> #topic Who is here?
+18:00:10 <dondelelcaro> Don Armstrong
+18:01:16 <bdale> Bdale Garbee
+18:01:36 <keithp> Keith Packard
+18:01:59 <dondelelcaro> we have regrets from aba and cjwatson
+18:02:02 <vorlon> Steve Langasek
+18:02:10 <dondelelcaro> I think that's everyone accounted for?
+18:02:17 <dondelelcaro> #topic Next Meeting?
+18:03:02 <dondelelcaro> currently the next meeting is the 18th instead of christmas day; does that still work for everyone?
+18:03:16 <bdale> fine with me
+18:03:21 <keithp> wfm
+18:03:56 <dondelelcaro> #action dondelelcaro to ask aba and cjwatson if the 18th of December works for them still
+18:04:22 <dondelelcaro> #topic #769972 New member selection process
+18:04:38 <vorlon> yeah, fine with me
+18:04:41 <dondelelcaro> cool
+18:04:49 <dondelelcaro> we've gotten a number of responses here, and a number of acks. I'm still waiting on a few more people to respond
+18:05:06 <bdale> yep, thanks for taking the lead on poking for acks
+18:05:09 <dondelelcaro> no problem
+18:05:20 <bdale> so our habit has been to deliberate on the list in private
+18:05:26 <bdale> I assume we want to continue that?
+18:05:37 <dondelelcaro> I think so
+18:05:44 <bdale> if so, we should confirm that we know the list of subscribers on the private list has been updated
+18:05:54 <dondelelcaro> OK
+18:06:13 <dondelelcaro> I think I know where that is, so I can verify it
+18:06:24 <bdale> once that's done, an email to that list with the list of candidates nominated, and who has accepted or declined the nomination, should go to the private list
+18:06:31 <dondelelcaro> #action dondelelcaro to verify the debian-ctte-private list subscribers is accurate
+18:06:39 <dondelelcaro> right
+18:07:01 <bdale> I know your text to the nominees said those who accept might be publicly acknowledged, but that has not been our habit in the past
+18:07:17 <dondelelcaro> bdale: well, it has to be
+18:07:23 <dondelelcaro> bdale: either during discussion, or when we vote
+18:07:34 <bdale> not at all clear
+18:07:43 <dondelelcaro> unless we're just going to vote Y/N on someone?
+18:08:18 <bdale> last time, we discussed the nominees privately and reached consensus on who to put forward to the DPL
+18:08:34 <keithp> so the public vote is a mere formality?
+18:08:42 <bdale> it has been in the past
+18:09:00 <dondelelcaro> hrm...
+18:09:12 <bdale> if we can't reach consensus and actually need condorcet-style voting to decide who to put forward, that would be a new experience
+18:09:16 <dondelelcaro> §6.2 says "However, votes on appointments must be public."
+18:09:30 <bdale> right, which is why we always hold a public vote
+18:09:32 <dondelelcaro> s/6.2/6.3.4/
+18:09:57 <bdale> said vote has always followed a process of reaching private consensus, as a way of "not embarrassing" candidates who were not chosen
+18:10:00 <vorlon> but AFAICS that only requires a public up/down vote on a given appointment
+18:10:11 <dondelelcaro> we must have had this discussion last time, and I'm just misrembering our consensus
+18:10:14 <dondelelcaro> OK
+18:10:26 <bdale> I'm not trying to say that we *have* to do it this way, but as the person who now has the longest length of service, I'm just trying to explain how it's been done in the past
+18:10:27 <dondelelcaro> yeah, that all seems reasonable
+18:10:37 <Mithrandir> (you did have approximately this discussion last time too, yes)
+18:10:46 <bdale> we always do .. ;-)
+18:10:57 <Mithrandir> except that last time, you didn't agree on keithp vs pkern and so that bit was public, IIRC.
+18:11:23 <dondelelcaro> and I probably made the same arguments too. ;-)
+18:11:48 <bdale> so, to be clear, I'm all for openness and not trying to drive a particular process here
+18:12:10 <bdale> I *do* want us to drive to at least 2 nominations for DPL approval with due haste, however
+18:12:17 <dondelelcaro> right
+18:12:41 <dondelelcaro> OK. should we close nominations?
+18:12:59 <keithp> bdale: 6.3.4 seems to encourage private discussions as a process at least
+18:13:00 <bdale> on the assumption that one of the options imposing term limits passes GR, having enough time for new people to come up to speed before I (and possibly vorlon) get the boot late in 2015 seems prudent
+18:13:12 <ansgar> How does the voting work if you need >1 candidate?
+18:13:27 <bdale> nothing says we can't do a consensus ranking in private
+18:13:57 <bdale> if we were to do so and the top N were obvious, running a public y/n vote on the top N as those to propose to the DPL could happen and be completely "legal"
+18:13:58 <keithp> ansgar: I think the public appearance is that individual ballots for each proposed member be voted on
+18:14:13 <dondelelcaro> right
+18:14:41 <dondelelcaro> yeah, either one would be OK
+18:14:57 <keithp> the goal is to build a ctte with broad experience and knowledge, sometimes that means picking a suitable set of candidates ensuite
+18:15:05 <dondelelcaro> does anyone object to keeping the nominations list private?
+18:15:25 <bdale> the whole public/private thing has always been a subject it's worth our discussing explicitly. trust works both ways here. we want to be able to openly and honestly discuss candidate qualifications within the ctte, I at least feel we owe it to the ones not selected to not air all their dirty laundry in public
+18:15:43 <dondelelcaro> right
+18:16:00 <keithp> bdale: perhaps summarize the positive qualifications of each proposed candidate as a part of our submission to the DPL?
+18:16:13 <bdale> not a bad thought
+18:16:38 <keithp> Give the DPL an understanding of our reasoning at least
+18:16:55 <keithp> (and the rest of the project in parallel)
+18:16:59 <bdale> vorlon: any thoughts regarding this?
+18:17:14 <vorlon> sorry, brain contention with work stuff
+18:17:19 <bdale> np
+18:17:36 <bdale> <dondelelcaro> does anyone object to keeping the nominations list private?
+18:17:36 <vorlon> this is the public/private question?
+18:17:45 <bdale> correct
+18:17:45 <vorlon> I greatly prefer them to be kept private
+18:17:49 <bdale> ok
+18:17:54 <bdale> then Don, the answer is known
+18:18:06 <dondelelcaro> #agreed keep nomination list private
+18:18:12 <keithp> vorlon: I suggested that perhaps we summarize our reasoning for the proposed candidates in our note to the DPL
+18:18:13 <vorlon> in theory people can be comfortable putting themselves forward without having the TC publically rejecting them
+18:18:18 <dondelelcaro> right
+18:18:24 <bdale> agreed
+18:18:34 <bdale> and I like Keith's suggesting
+18:18:36 <vorlon> I don't think we are under any obligation to even share the full list of candidates with the DPL
+18:18:42 <bdale> we are not
+18:19:07 <dondelelcaro> does anyone have an objection to me thanking everyone (in general) who was nominated and agreed to be considered, and then drawing the nominations to a close in say, 48 hours?
+18:19:11 <bdale> the whole idea of publicly asking for nominations is relatively new
+18:19:15 <vorlon> or maybe "proposed candidates" means just the ones we are recommending to the DPL?
+18:19:19 <keithp> I volunteer to write up the summaries, iterating in private
+18:19:25 <bdale> dondelelcaro: good plan
+18:19:28 <vorlon> dondelelcaro: sounds good to me
+18:19:36 <dondelelcaro> OK.
+18:19:39 <keithp> dondelelcaro: agreed
+18:19:44 <bdale> feel free to mention that deliberations will be conducted in private
+18:20:10 <dondelelcaro> #action dondelelcaro to thank everyone (in general) who was nominated and agreed to be considered, and drawing nominations to a close in 48 hours, indicate that delibrations will happen in private
+18:20:41 <dondelelcaro> I've got the list of nominees and all of the mails, so I'll send that to ctte-private to summarize everything
+18:20:46 <bdale> thank you
+18:21:08 <dondelelcaro> #topic #636783 constitution: super-majority bug
+18:21:29 <dondelelcaro> I've got all of these still on the agenda; does anyone object to just skipping them until after the TC retirement vote?
+18:21:42 <bdale> I would be pleased with that
+18:22:08 <bdale> I do think we have enough stuff to call for a GR at some point, but I'd like to table this until after the current GR closes
+18:22:15 <dondelelcaro> sounds good
+18:22:26 <keithp> one GR at a time seems like a pretty good plan
+18:22:27 <dondelelcaro> I'd also be OK with tabling it until after jessie releases
+18:22:34 <bdale> I'm fine with that too
+18:22:40 <bdale> we have more urgent items on our agenda, frankly
+18:22:50 <dondelelcaro> #agreed table #636783 until at least the GR is done, possibly jessie release
+18:22:58 <dondelelcaro> #topic #741573 menu systems and mime-support
+18:23:35 <dondelelcaro> keithp: I think this needed one more position for this, IIRC?
+18:23:43 * dondelelcaro can't remember if that got done or not
+18:23:44 <keithp> I've had a bunch of emails on this topic, one in particular caught my attention asked that we focus on resolving the issue brought to us and not attempt to rewrite policy ourselves?
+18:24:53 <dondelelcaro> OK
+18:24:56 <bdale> Russ had thoughts on that .. sorry he chose to resign before this concluded
+18:25:04 <keithp> any thoughts on that from the remaining members?
+18:25:46 * bdale waits for the BTS to paint in his browser...
+18:25:56 <keithp> I can't even reach the BTS today...
+18:26:50 <dondelelcaro> hrm; that's no good
+18:27:24 <bdale> so the original question was Plessy asking us to over-rule Bill's veto on the proposed policy change?
+18:27:35 <dondelelcaro> right
+18:27:37 <keithp> yes
+18:28:50 <ansgar> Well, Plessy asked for arbitration without specifying what that means in detail.
+18:28:53 <keithp> I think we can hold an up/down vote on that direct question pretty easily
+18:29:01 <vorlon> keithp: policy on this needs fixed, the standard policy process has failed, and someone needs to step up to get it sorted out; the suggestions that the TC should limit itself to the original question are way off base
+18:29:19 <ansgar> Ah, no it specifically asks for an override later.
+18:29:45 <hartmans> vorlon: It would be really cool if the TC documented that the policy process had failed and explained how.
+18:29:56 <keithp> vorlon: perhaps the TC should solicit policy editing proposals and then pick amongst them, rather than writing the changes ourselves then?
+18:30:01 <vorlon> whether we choose to make a recommendation vs. exercising one of the TC's firmer powers would be open to discussion
+18:30:07 <hartmans> I think that would make me and possibly Charles feel a lot more comfortable with a decision to write policy.
+18:30:19 <bdale> hartmans: good point. it appears consensus was reached, then ignored.
+18:30:20 <vorlon> keithp: I solicit a policy proposal from you
+18:31:04 <keithp> I wish I could see the full bug history now...
+18:31:26 <bdale> it painted for me, was just slow
+18:31:58 <vorlon> bdale: if there was someone disagreeing with the "consensus" and refusing to apply it, then it wasn't consensus
+18:32:23 <keithp> vorlon: 'rough consensus' doesn't mean unanimity
+18:32:56 <bdale> old argument .. "group as a whole" vs "everyone agreed"
+18:33:10 <dondelelcaro> our choices here are really 1) override 2) write policy ourselves 3) tell -policy to try again with CTTE guidance on policy, I guess?
+18:33:32 <bdale> I think so
+18:33:54 <keithp> dondelelcaro: or abstain from deciding, which is our current situation due to inaction
+18:33:57 <dondelelcaro> did we ever figure out what Bill's specific objections were to the policy?
+18:34:06 <bdale> I don't think so
+18:34:28 <dondelelcaro> would an ultimatum be useful here?
+18:34:35 <vorlon> keithp: our policy process isn't based on "rough consensus", but on a stricter definition of consensus
+18:34:53 <keithp> dondelelcaro: asking Bill to explain his issues or face an override?
+18:35:02 <dondelelcaro> keithp: right
+18:35:15 <bdale> Bill was CC'ed in but never joined the thread
+18:36:14 <dondelelcaro> yeah; that seems to be a common problem in these cases
+18:36:18 <keithp> dondelelcaro: something like 'we're inclined to agree with the plaintiff and override your veto and are interested in hearing cogent arguments supporting your position?'
+18:36:25 <dondelelcaro> keithp: right
+18:36:53 <dondelelcaro> does anyone object to that with a time limit? say 1 month?
+18:36:58 <dondelelcaro> or two weeks?
+18:37:00 <bdale> keithp: since you've taken the drafting lead, do you want to send that email?
+18:37:04 <keithp> bdale: will do
+18:37:11 <keithp> once I can reach the bug again :-)
+18:37:40 <bdale> we've let this go long enough that any decision will have no impact on jessie, so let's get on with it, but don't go nuts
+18:37:52 <keithp> also letting the policy team understand that I'm interested in *not* having the TC responsible for editing policy, but just enabling them to make progress with their normal process
+18:37:58 <vorlon> keithp: by "override the veto", however, you don't mean applying the original proposed policy change, do you?
+18:38:18 <keithp> vorlon: I can't see what that is at present...
+18:38:36 <vorlon> it's the much earlier proposal that should be superseded by the much better one that you drafted ;)
+18:38:42 <keithp> at this point, I can't actually recall the precise wording
+18:40:38 <dondelelcaro> should we just try the debian-policy consensus method for keithp's draft in the meantime?
+18:41:27 <keithp> dondelelcaro: I could bring my proposal to the policy team and see what they think, using their normal process
+18:41:30 <bdale> meaning you want to learn whether the current composition of the TC has consensus around keithp's current draft?
+18:42:13 <dondelelcaro> bdale: no, I meant bringing keithp's proposal to the policy team
+18:42:16 <bdale> ok
+18:42:25 <bdale> yes, that'd be a great step
+18:42:36 <bdale> if it achieves consensus there, we'd be done
+18:43:08 <dondelelcaro> vorlon: does that work for you?
+18:43:59 <dondelelcaro> I'll just assume that it does
+18:44:09 <vorlon> sure
+18:44:09 <dondelelcaro> and if not, it can be re-raised
+18:44:12 <dondelelcaro> cool
+18:44:34 <keithp> vorlon: shall I stick your seal-of-approval on my proposal?
+18:44:35 <dondelelcaro> #action keithp to bring his draft of #741573 to -policy for consensus building
+18:44:38 <dondelelcaro> heh
+18:44:43 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
+18:44:52 <dondelelcaro> oh, actually, let me throw a quickie in here
+18:45:07 <dondelelcaro> #topic #770789 df sizes output format
+18:45:22 <dondelelcaro> this is YE OLDE SI units vs 2^10 units
+18:45:40 <keithp> we're still having that discussion?
+18:45:41 <dondelelcaro> and frankly, I'm just going to punt this back to the maintainer to close
+18:45:50 <dondelelcaro> keithp: the bug submitter is notorious
+18:46:19 <dondelelcaro> does anyone object to a quick "we decline to override the maintainer" draft for this issue? [should we even bother?]
+18:46:56 <keithp> Sounds good to me
+18:47:07 <ansgar> +1
+18:47:36 <ansgar> Also the documentation says "print sizes in powers of 1024" for -h vs. "
+18:47:42 <dondelelcaro> #action dondelelcaro to draft "we decline to override the maintainer" for #770789
+18:47:46 <ansgar> print sizes in powers of 1000" for -H. Seems pretty clear.
+18:47:51 <dondelelcaro> ansgar: yeah, I'm pretty sure the documentation is correct
+18:47:53 <vorlon> keithp: if it's the same proposal, yes
+18:48:18 <bdale> dondelelcaro: thumbs up from me
+18:48:24 <keithp> vorlon: I'll probably take an editing pass to make sure it says what I mean, and run that past you if you're willing
+18:48:25 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
+18:48:56 <ansgar> For the init upgrade I think there were three proposals.
+18:48:59 <dondelelcaro> (on the previous bug, I'm wondering if we shouldn't require a DD to raise the issue to the CTTE; we can obviously approve it ourselves)
+18:49:10 <vorlon> keithp: +1
+18:50:04 <dondelelcaro> so for this bug, I'm happier that we actually have concrete proposals, though I don't think any of them have had enough testing
+18:50:29 <ansgar> I think two had issues with installing sysvinit in some cases.
+18:50:39 <ansgar> And the last one just arrived ~2 hours ago.
+18:50:48 <Mithrandir> ansgar: the xen console one?
+18:51:47 <vorlon> dondelelcaro: there's a fundamental question here that we've kind of leap-frogged over
+18:51:57 <ansgar> First proposal in 762194#124, I tested it in #142
+18:52:12 <dondelelcaro> vorlon: whether we should actually switch the defaults?
+18:52:14 <vorlon> which is whether we agree that users *should* be kept on sysvinit on upgrade, if we find a workable solution
+18:52:17 <vorlon> yes
+18:52:54 <hartmans> If you haven't read <5e27043707590dc20fb0b0b083912d92@iwakd.de then I recommend it.
+18:52:56 <keithp> vorlon: I don't think we leap-frogged; we asked first whether that was even possible
+18:53:21 <dondelelcaro> vorlon: right; I think that's the "decline to overide init maintainers" option, which I believe should be an option in this vote
+18:53:23 <hartmans> It seems to have a good sumarry of the proes/cons of switching; seems to have good analysis of the proposals; and also very interesting discussion of jessie+2
+18:53:28 <ansgar> Then there's #157 (totally untested AFAIK).
+18:53:48 * dondelelcaro really should make msg-id searching work for the BTS
+18:53:59 <vorlon> keithp: however, if the consensus within the TC is that an upgrade *should* automatically switch, then we should stop wasting folks' time trying to come up with proposals on how to avoid it
+18:54:03 <hartmans> That's the one from Christian Seiler
+18:54:33 <vorlon> (this was why I dissented on Diziet's last resolution on this subject)
+18:54:52 <dondelelcaro> vorlon: true... I must admit that I think we should switch by default
+18:55:42 <dondelelcaro> vorlon: I was hoping that someone would come up with some good way to switch by default, but provide an easier method for people to opt out in detectable configurations (or providing a "boot with sysvinit" option in grub, or something like that)
+18:56:09 <ansgar> dondelelcaro: There's a patch for boot-with-sysvinit option in grub written by the systemd people.
+18:56:11 <Mithrandir> dondelelcaro: cjwatson has said he'll provide a "boot with sysvinit" option in grub, afaik.
+18:56:11 <dondelelcaro> does anyone on the CTTE currently think that we shouldn't be switching on default?
+18:56:33 <dondelelcaro> ansgar, Mithrandir: right, that's actually why I was thinking of it. ;-)
+18:56:49 <ansgar> #757298
+18:56:49 <keithp> dondelelcaro: would the resulting system be bootable with sysvinit by setting the appropriate kernel command line option?
+18:57:00 <vorlon> right; we can't actually detect problems during the upgrade and make a change to which packages we'll install as part of that upgrade, because that would be incestuous within the package manager
+18:57:01 <dondelelcaro> keithp: I believe so
+18:57:07 <ansgar> keithp: Yes, init=/lib/sysvinit/init
+18:57:12 <keithp> dondelelcaro: Mithrandir says it would be as well
+18:57:14 <vorlon> but maybe we can detect and flag it to grub
+18:57:34 <Mithrandir> keithp: sysvinit in jessie ships init as /lib/sysvinit/init, iirc.
+18:57:40 <vorlon> or at least flag it to the admin, and give 'install sysvinit-core' as one of the suggestions
+18:57:44 <Mithrandir> so you just need to point the kernel's init argument in that direction.
+18:57:57 <vorlon> AIUI, Md was already planning on doing inittab detection on upgrade
+18:58:04 <keithp> Mithrandir: and make sure that sysvinit is installed
+18:58:05 <Mithrandir> both systemd's and upstart's command line tools know how to speak the telinit protocol
+18:58:12 <Mithrandir> keithp: it's essential in wheezy
+18:58:13 <vorlon> and cjwatson was planning on providing cleaner grub selection
+18:58:19 <dondelelcaro> would an option that says "we decline to override init system maintainers; noting good discussion with #757298 and similar methods to enable sysvinit in specific custom setups"
+18:58:29 <dondelelcaro> be acceptable in principle?
+18:58:57 <Mithrandir> so if you do a plain upgrade and then don't remove packages, it'll be there. If you upgrade, then remove sysvinit (either directly or because it's unused), there's little that can be done.
+18:59:19 <Mithrandir> unused → marked as unused in apt, so removed with apt-get autoremove.
+18:59:34 <keithp> Mithrandir: as long as the autoremove is done after the system is running, that seems fine
+18:59:48 <keithp> I think the concern is that the upgrade result in a system that doesn't boot
+19:00:16 <bdale> right
+19:00:26 <ansgar> sysvinit should not be marked as automatically installed.
+19:00:31 <Mithrandir> keithp: autoremove has to be called by the admin, it's not called automatically.
+19:00:43 <dondelelcaro> ansgar: yeah, I would think it wouldn't be by default either. You'd have to do it manually
+19:00:45 <ansgar> Everything debootstrap installs counts as "manually installed" as far as I know.
+19:00:55 <dondelelcaro> though I haven't tested that
+19:01:09 <keithp> Mithrandir: sounds good
+19:01:09 <ansgar> Also also did to keep sysvinit everywhere so far.
+19:01:15 <ansgar> s/Also/I/
+19:01:52 <dondelelcaro> ansgar: sounds good. I suppose if not, someone could provide a Suggests: sysvinit in the init package for a release
+19:01:52 <Mithrandir> keithp: at some point, it's the user shooting their foot off. We can make it harder for them, but we can't prevent it completely.
+19:02:19 <keithp> Mithrandir: memories of the grub->grub2 transition are painful for some :-)
+19:02:45 <Mithrandir> in addition to the earlier mentioned changed inittab detection, the plan is, afaik, to detect known-problematic fstabs too.
+19:03:04 <Mithrandir> keithp: sure, I'm not trying to downplay the possible pain.
+19:03:29 <helmut> doesn't the alternate dependency of "init" on sysvinit-core already prevent autoremoval?
+19:03:46 <dondelelcaro> helmut: dunno
+19:03:59 <ansgar> helmut: No. sysvinit-core is not installed.
+19:04:02 <Mithrandir> helmut: that won't prevent autoremoval of sysvinit.
+19:04:31 <dondelelcaro> anyway, I think these issues can be discussed elsewhere; does anyone object to such an option?
+19:04:40 <dondelelcaro> 10:58:26 <dondelelcaro> would an option that says "we decline to override init system maintainers; noting good discussion with #757298 and similar methods to enable sysvinit in specific custom setups"
+19:04:54 <dondelelcaro> do we need to keep spending people's time on non-upgrade options?
+19:05:05 <dondelelcaro> s/upgrade/switch-on-&/
+19:05:09 <vorlon> I would go further
+19:05:33 <bdale> vorlon: ?
+19:05:42 <keithp> dondelelcaro: options that let people declare as a part of the upgrade process to not switch still seem useful, but it looks like we have good options already
+19:05:45 <vorlon> if we actually agree with this in principle, I'd like an affirmative resolution saying that we recommend/support systemd being the default init system for upgrades as well as new installs
+19:07:20 <keithp> vorlon: just as a '6.1.5 Offer advice' motion, that seems good to me
+19:07:28 <dondelelcaro> I'm personally OK with that as well
+19:07:35 <dondelelcaro> vorlon: do you want to draft that? or should I?
+19:08:06 <dondelelcaro> (we're also running a bit over time here)
+19:08:42 <vorlon> dondelelcaro: depends on how soon we expect it done
+19:08:59 <dondelelcaro> well, I can start drafting it, and you can modify it
+19:09:00 <dondelelcaro> heh
+19:09:08 <dondelelcaro> probably would be good to get to it sooner rather than later
+19:09:34 <dondelelcaro> #action dondelelcaro to draft affirmative resolution on #762194 noting #757298 et al
+19:09:41 <dondelelcaro> #topic #766708 Request to override gcc maintainer changes breaking multiarch packages
+19:10:32 <vorlon> dondelelcaro: that sounds like a plan :)
+19:11:06 <dondelelcaro> on #766708, I think we might be too late for jessie
+19:12:20 <dondelelcaro> I'm sort of unhappy about this bug, for too reasons: 1) it was brought to the CTTE really quickly without any attempt at concensus 2) The changes were made so close to the release of jessie that anyone who disagreed basically had no option
+19:12:35 <dondelelcaro> I don't know how to express that in a constructive way, though
+19:12:36 <keithp> seems like this bug only targets jessie to me; after that, it seems like there's reasonable consensus that using better supported mechanisms is the right way?
+19:13:37 <helmut> keithp: no. #771070
+19:14:26 <dondelelcaro> keithp: I think there's agreement that there might be a better method, but disagreement as to whether the other method even works or can work
+19:14:43 <keithp> yeah
+19:15:04 * dondelelcaro honestly hasn't done enough work in this particular multi-arch space to speak with even modest authority on it, though
+19:15:21 <bdale> I haven't either .. I did see 771070, though
+19:15:36 <keithp> and I even maintain a GCC package in the archive...
+19:15:41 <dondelelcaro> heh
+19:15:52 <keithp> (non self-hosting though)
+19:16:50 <keithp> I am starting to get a sense of the politics here though, and of course both sides have valid points...
+19:16:59 <bdale> my sentiment too
+19:17:04 <dondelelcaro> yeah
+19:17:30 <dondelelcaro> maybe the right solution is for someone to pay for a sprint, and force all of the major parties to sit in a room together and figure this out
+19:17:41 <vorlon> well
+19:17:44 <helmut> (that did happen in august)
+19:17:46 <vorlon> the parties were all at a sprint
+19:17:47 <vorlon> yeah
+19:17:52 <dondelelcaro> oh. right.
+19:18:03 <vorlon> clearly they did not all come away with the same understanding after that one
+19:18:10 <Mithrandir> shouldn't have let them fly home until they were in agreement, then. :-P
+19:18:12 <dondelelcaro> we never get easy solutions here! ;-)
+19:18:14 <keithp> helmut: can you summarize for me what about the old solution doesn't meet 771070's desires?
+19:18:28 <vorlon> AIUI everyone believed there was an agreement ;)
+19:18:49 <helmut> keithp: which one is "old"?
+19:18:49 <keithp> vorlon: shipping code should have been a requirement then
+19:19:09 <keithp> helmut: the one used by the existing packages that actually results in working compilers
+19:19:51 <vorlon> keithp: sorry, a requirement for what?
+19:20:02 <keithp> vorlon: for letting them go home
+19:20:08 <vorlon> well
+19:20:24 <vorlon> the shipping of the code is, AIUI, the problem
+19:20:27 <helmut> keithp: primary arguments being made: 1) cross architecture build-depends not supported by infrastructure 2) multiarch version lock frequently results in bd-uninstallable 3) the actual packages are not able to cross build gcc (lacking languages)
+19:20:52 <keithp> helmut: thanks
+19:20:58 <helmut> keithp: non-exhaustive
+19:21:01 <keithp> sure
+19:22:13 <helmut> could someone voice wookey? (he fails to register with nickserv atm)
+19:22:49 <wookey> thank you
+19:23:08 <wookey> the argreement was that whatever was working first would get uploaded
+19:23:40 <wookey> keithp: the main disgreemnet is actually about multilib support AIUI
+19:24:05 <wookey> the existing (in unstable) toolchains are one-arch each
+19:24:20 <vorlon> wookey: doko has pointed out to me privately that this was never an agreement
+19:24:27 <dondelelcaro> (is everyone still good on time?)
+19:24:30 <helmut> reference: 20140829095214.GV19999@stoneboat.aleph1.co.uk section 3.13
+19:25:10 <bdale> I just negotiated peace with my wife .. so I'm ok for a while longer
+19:25:36 <wookey> vorlon: well I honestly don't understand that.
+19:26:20 <vorlon> then I guess that's the crux of the misunderstanding
+19:26:21 <wookey> but it's true that I don;t think he helped write the report afterwards. The rest of us ended up doing it (all on the wiki)
+19:26:54 <wookey> but this is very old arguement anyway. The bootstrap meet was just re-iteration 8 or so
+19:27:24 <wookey> WR jessie I think the question is, will 4.9.2-X migrate?
+19:27:39 <wookey> if not then there is nothing to decide on this usefully
+19:28:07 <wookey> and we can punt to the more substantive 770070 (?)
+19:28:31 <dondelelcaro> does 4.9.1 still carry the multi-arch cross patches?
+19:28:51 <wookey> the patch to the 4.9.1-19 in jessie is the 5-liner that started this bug
+19:28:53 <helmut> dondelelcaro: the jessie version carries most (minus two hunks) the sid version doesn't
+19:29:01 <wookey> the patch the what is now in unstable is 5K
+19:29:06 <dondelelcaro> OK
+19:29:12 <wookey> there is a big difference in maintenance burden
+19:29:30 <wookey> (if we decide to maintain it outside gcc)
+19:30:26 <wookey> although of course versoins don;t change often in jessie, so it's do-able, just very annoying
+19:30:34 <helmut> in my other mail I asked, about options for action on the gcc/jessie issue. are there any options left?
+19:30:46 <keithp> wookey: it does seem like a practical solution for jessie then
+19:31:27 <dondelelcaro> so I guess we can punt for jessie, but we need to address this issue more substantiatively going forward
+19:31:29 <wookey> _if_ a new gcc is not going to migrate, but I suspect there are serious bugs which mean that will happen?
+19:31:33 <helmut> i.e. are we discussing the 766708 or 771070 atm?
+19:31:39 <dondelelcaro> helmut: both
+19:31:40 <wookey> I don;t know...
+19:31:54 <wookey> mostly 766708, I thought
+19:32:05 <dondelelcaro> yeah, mainly #766708, but they're sort of inter-related
+19:32:07 <keithp> helmut: I'm trying to focus on 766708 as that seems more pressing for jessie
+19:32:19 <keithp> (if not, in fact, already too late)
+19:32:30 <vorlon> my understanding is that the trigger for the changes in gcc-4.9 was the upload of the cross-toolchain packages to the archive, which imposes a maintenance burden on the gcc maintainers, and was not agreed with them
+19:32:56 <vorlon> and that, from doko's POV, these uploads happened over his explicit objection
+19:33:13 <vorlon> (but there's no need to try to adjudicate what was or wasn't said/agreed at the sprint)
+19:33:40 <vorlon> so if there was agreement to not include these toolchain packages in the archive, and they were withdrawn, doko might be willing to reenable this code path for jessie?
+19:33:55 <vorlon> if that happened, would that be an improvement from your (helmut/wookey) pov?
+19:35:12 <wookey> hmm, not sure. $people still want toolchains in unstable too, so the argument remains the same
+19:35:22 <wookey> but I guess it might
+19:35:36 <dondelelcaro> wookey: I suppose we'd address the issues for unstable when we tackle #771070
+19:35:43 <wookey> this code was happily in gcc for 2 years....
+19:35:53 <vorlon> we can deal separately with the question of whether gcc-4.9 will migrate or not. If there's agreement on the technical solution, we could talk with the release team about using testing-proposed-updates
+19:36:21 <wookey> dondelelcaro: right
+19:36:42 <dondelelcaro> ok
+19:37:24 <wookey> so we'd move the unstable toolchains to experimental?
+19:37:27 <dondelelcaro> so lets try to get agreement around this for jessie via tpu, and then tackle the complete question in a more thourough discussion
+19:37:53 <dondelelcaro> (sorry that we're being so late here)
+19:38:18 <wookey> I have started a long answer to 771070, but not finished yet.
+19:38:31 <keithp> from my perspective, I wonder if wookey thinks that reasonable cross compilers can be built with doko's preferred approach
+19:38:34 <vorlon> if we were able to ensure they stayed in experimental, it seems to me that would relieve the support burden on the gcc maintainers
+19:38:45 <helmut> vorlon: my reason for forwarding this to the ctte was that suddenly there was *no* way to build cross compilers. I don't care much as long as it works, I summarized the bugs with the supported method on the ctte bug
+19:38:49 <vorlon> since responsibility for keeping those packages buildable/installable would lie solely with the cross-toolchain maintainer
+19:39:05 <dondelelcaro> #agree get agreement to #766708 around pulling the cross-packages (to experimental?), reinstate patches, etc.
+19:39:17 <dondelelcaro> ok. I'm going to move on, because I'm running out of time myself
+19:39:21 <dondelelcaro> #topic #750135 Maintainer of aptitude package
+19:39:22 <vorlon> helmut: right; I'm trying to identify a compromise here that meets your needs while also addressing the underlying reason doko made the change
+19:40:03 <dondelelcaro> #action aba to propose a process to try out on #750135 Including the maintainer perhaps providing private response to us, and also perhaps an irc conversation
+19:40:20 <dondelelcaro> this one is still here; I think we might need to do something more specific on it, but not now
+19:40:31 <dondelelcaro> #topic Additional Business
+19:40:37 <bdale> none here
+19:40:44 <dondelelcaro> as a note, I've started using usertags for the bugs
+19:40:53 <dondelelcaro> and I've gotten rid of the useless standard sorting for ctte bugs
+19:41:11 <wookey> keithp: it is possible to build _reasonable_ compilers (ubuntu has some). I don't think it's the best way, or a nice thing to maintain. But yes it's possible. We'll explore that in the other bug.
+19:41:34 <keithp> wookey: thanks.
+19:41:41 <dondelelcaro> (if someone hates it, let me know. I'll try to document it in the git eventually)
+19:42:20 <KGB-3> \ f\ 303Don Armstrong\ f \ 305master\ f dbce33b \ 306debian-ctte\ f \ 310meetings/agenda.txt\ f remove bug which is merged with #766708
+19:42:27 <wookey> the real issue was that _before_ that was working we got 'turned off' :-)
+19:42:54 <dondelelcaro> anything else?
+19:42:56 <keithp> wookey: I hope we can fix that without causing long-term pain in GCC.
+19:43:04 <wookey> indeed
+19:43:07 <keithp> nothing from me
+19:43:17 <bdale> dondelelcaro: thanks again for running the meeting, Don!
+19:43:19 <dondelelcaro> #endmeeting
\ No newline at end of file
projects / debian-ctte.git / commitdiff