17:00:39 <dondelelcaro> #startmeeting
17:00:39 <MeetBot> Meeting started Thu Sep 25 17:00:39 2014 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:39 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:00:40 <keithp> good morning
17:00:47 <dondelelcaro> #topic Who is here?
17:00:50 <dondelelcaro> Don Armstrong
17:00:56 <keithp> Keith Packard
17:01:05 <dondelelcaro> keithp: morning!
17:01:10 <keithp> Hola!
17:02:20 <keithp> As usual, the impeding meeting encouraged me to do some ctte work this morning :-)
17:02:24 <dondelelcaro> heh
17:02:47 <dondelelcaro> trying to identify the rest of our participants
17:03:29 <cjwatson> argh sorry, I can't make it tonight, Kirsten has karate practice and I have neglected to realise far enough in advance to arrange alternate childcare cover
17:03:37 <dondelelcaro> cjwatson: no worries
17:03:50 <keithp> cjwatson: you'll have more fun than we will anyways
17:05:05 <dondelelcaro> I think I've pinged everyone now; rra isn't on IRC right now
17:05:21 <keithp> bdale was around an hour ago
17:06:12 <dondelelcaro> Diziet just told me that he won't be able to make it
17:07:44 <keithp> pinged bdale via sms
17:07:58 <dondelelcaro> well, I'll at least get the next meeting on the calendar, and I'll try to at least get the agenda into shape
17:08:11 <dondelelcaro> #topic Next Meeting?
17:08:48 <keithp> meetings.ics has a bug in it at present
17:09:03 <dondelelcaro> the next meeting is currently scheduled for the 30th;
17:09:11 <keithp> that works for me
17:09:21 <dondelelcaro> keithp: ah, wouldn't surprise me... I hand write it
17:09:30 <keithp> shall I push the fix?
17:09:34 <dondelelcaro> absolutely
17:10:09 <bdale> Bdale Garbee
17:10:17 <bdale> sorry I'm late .. packing for move this Sat is underway!
17:10:23 <keithp> bdale: I figured as much!
17:10:39 <keithp> cjwatson and Diziet both send regrets
17:10:48 <bdale> ok
17:10:55 <KGB-3> 03Keith Packard 05master 40ee6c3 06debian-ctte 10meetings.ics Fix typo in meetings.ics
17:11:02 <dondelelcaro> next meeting is currently date -d 'Thu Oct 30 2014 17:00 UTC'
17:11:29 <dondelelcaro> I think that might be after the end of DST in europe, so it might switch the time slightly
17:11:41 <bdale> 10/30 is an all-day LF board meeting, but I can probably participate in an IRC meeting here in parallel
17:11:50 <dondelelcaro> OK
17:12:26 <dondelelcaro> #agreed next meeting is currently date -d 'Thu Oct 30 2014 17:00 UTC'
17:12:45 <dondelelcaro> I guess since there are three of us, we can at least go through the agenda items and get things back up to date
17:12:48 <dondelelcaro> #topic #717076 Decide between libjpeg-turbo and libjpeg8 et al.
17:13:16 <dondelelcaro> I think this was taken care of, so it probably shouldn't be on the agenda
17:13:28 <dondelelcaro> #topic #636783 constitution: super-majority bug
17:14:33 <dondelelcaro> I think the last thing that happened here was two action items for Diziet
17:14:44 <dondelelcaro> #action Diziet to integrate text as asked by Matthew V
17:14:53 <dondelelcaro> #action Diziet to put resolution integrated text into git
17:15:14 <dondelelcaro> an[y
17:15:15 <keithp> agreed
17:15:19 <dondelelcaro> any other comments here?
17:15:27 <bdale> nope
17:15:31 <keithp> nope
17:16:12 <dondelelcaro> #topic #636783 constitution: casting vote
17:16:26 <dondelelcaro> also needing Diziet action
17:16:33 <bdale> I kind of have the set of constitution items lumped together in my mind .. skip past them?
17:16:37 <dondelelcaro> #action Diziet to draft casting vote to 3 options: change to 9 with casting, change to 9 without casting, FD
17:16:44 <dondelelcaro> yeah, I'll skip them
17:16:55 <dondelelcaro> I just want to hit them and shove the action items back in
17:17:02 <dondelelcaro> #topic #636783 constitution: minimum discussion period
17:17:03 <bdale> I look forward to Diziet's next round of proposals, but no need to flail in the meantime
17:17:11 <bdale> ok
17:17:18 <dondelelcaro> #action diziet to draft a proposal
17:17:28 <dondelelcaro> #topic #636783 constitution: TC member retirement/rollover
17:17:39 <dondelelcaro> #action diziet to draft a proposal (actually for this one; the previous was skipped)
17:17:56 <dondelelcaro> #topic #636783 constitution: TC chair retirement/rollover
17:18:17 <dondelelcaro> #action Diziet to draft TC election automatic trigger on new TC member, and manual trigger by another TC member ?
17:18:22 <dondelelcaro> #topic #681419 Depends: foo | foo-nonfree
17:18:42 <dondelelcaro> I think vorlon called for votes on this
17:19:04 <keithp> I voted
17:19:06 <dondelelcaro> ah, right
17:19:08 <dondelelcaro> I voted too
17:19:18 <dondelelcaro> I'll clean this one up and announce the decision
17:19:27 <keithp> sounds right
17:19:30 <dondelelcaro> #action dondelelcaro to finalize voting for #671418 and announce decision
17:19:53 <dondelelcaro> #topic #741573 menu systems and mime-support
17:20:15 <dondelelcaro> keithp: I think this one is yours currently, right?
17:20:23 <keithp> yes
17:20:31 <keithp> I wrote up a list of potential ballot items and posted that
17:20:58 <keithp> I would like to get consensus on that list, so I think we can make progress here today by deleting ones that we don't like
17:22:40 <keithp> can the two of you see that email? (it's also in the repo under bug 741573)
17:23:26 <dondelelcaro> keithp_alternatives.txt, right?
17:23:31 <keithp> yes
17:24:36 <bdale> reading
17:25:09 <dondelelcaro> I think that #1, #6, and #7 probably aren't necessary
17:25:17 <keithp> first question is whether those capture the range of potential ballot items
17:25:23 <bdale> yeah, 7 is just like 8
17:25:44 <keithp> bdale: it's slightly different in that we would say we weren't interested in ever deciding
17:25:44 <dondelelcaro> I think so; there's not something that I would want to vote for that isn't there
17:26:11 <bdale> I see your point, but I don't think that's practically different than FD
17:26:24 <bdale> and I also don't think it'd be the winning option, so it just feels like clutter
17:26:38 <keithp> agreed, I think we should remove it
17:26:47 <bdale> so you don't have an 'allow either, prefer desktop' kind of entry
17:26:48 <keithp> I just wanted to have it listed for completeness
17:27:12 <bdale> I guess that's sort of like 3
17:27:57 <bdale> bounding 'require' in the context of policy might help me think about it
17:28:01 <keithp> depends on if you think recommendations are ever listened to, or if we need 'requires' to have any effect
17:28:34 <bdale> ok
17:30:03 <keithp> So, the other big question is what the scope of the menu systems should be; right now, the policy says 'anything that runs without arguments' should have a menu entry
17:31:05 <dondelelcaro> yeah; I think that's a mistake unless there is a command line menu I don't know about
17:31:16 <bdale> which is clearly the opinion of 'menu' advocates, but I'm not there
17:31:37 <keithp> well, both menu and desktop allow for entries for applications that only run in a terminal
17:32:13 <keithp> so, one option would be to define a policy for applications that *want* a menu entry, and a separate recommendation for the class of applications which should want a menu entry
17:32:23 <bdale> but isn't that meant in the desktop case for things where a terminal window needs to be launched to run it, not so much for a "things you might want a command line menu for"?
17:32:38 <bdale> ok
17:32:42 <bdale> sure, we could use it that way
17:32:43 <keithp> I think that's nominally the same list
17:33:24 <keithp> policy currently says that applications that run without options 'should' have a menu entry
17:33:44 <keithp> I think that's about right; gives packagers the right to *not* have a menu entry if they  think it's silly
17:33:53 <keithp> while generally encouraging menu entries
17:34:07 <bdale> ok, I agree
17:34:13 <dondelelcaro> ok; that seems fine to me too
17:35:05 <keithp> moreover, the issue brought to the tech-ctte was solely about how to provide menu entries, not when to provide entries, so we'd be increasing the scope of the answer by doing that
17:35:46 <dondelelcaro> right
17:36:02 <dondelelcaro> and I think policy has it right currently, and if someone on the CTTE disagrees, we can always go to policy to change it
17:36:16 <keithp> iwj has pushed a draft of 4)
17:37:03 <keithp> If that's as far as he thinks we need to go in that direction, perhaps we can not have 1-3 on the ballot?
17:38:01 <keithp> so, require some menu, require desktop/allow menu, require desktop/disallow menu, fd
17:39:03 <bdale> pass that by iwj, and if he's ok with that list, we go with it?
17:39:09 <dondelelcaro> sounds good to me
17:39:30 <bdale> if he wants a 'require menu' option, I'm happy to have it on the ballot
17:39:33 <keithp> ok. I'll write up a ballot with his content for that option, new content for 5) and my content for 6
17:39:45 <bdale> ok
17:40:15 <dondelelcaro> #action keithp to write up a ballot with iwj's content for that option, new content for 5) and my content for 6
17:40:32 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
17:40:34 <keithp> How long to wait with that before asking for a vote? Or should I pend that until the next meeting?
17:40:36 <aba> sorry, very late
17:40:59 <dondelelcaro> keithp: probably post it to the list, then see if anyone responds in a week?
17:41:04 <keithp> sounds good
17:41:15 <dondelelcaro> (less if you get positive responses)
17:41:17 <dondelelcaro> aba: no worries
17:41:46 <dondelelcaro> from what I can tell from the discussion on list, most people seem agreed that we shouldn't automatically switch to systemd on upgrade
17:42:00 <dondelelcaro> vorlon sends his regrets too
17:42:01 <keithp> I have to agree with that; it can really break things
17:42:06 <bdale> I agree
17:42:23 <bdale> default for new installs != auto-upgrading
17:42:24 <aba> same as e.g. with exim3 to exim4
17:43:08 <keithp> what do you do to people running gnome though?
17:43:20 <dondelelcaro> dunno
17:43:24 <bdale> that's the big question
17:43:30 <keithp> 'sorry for your poor life choices'?
17:43:39 <bdale> harsh
17:43:47 <jcristau> i don't understand why we wouldn't want to get systemd on upgrade
17:43:55 <bdale> the last discussion I read was about how to prompt in such cases and what to say
17:43:56 <aba> Install a new metapackage with pulls in systemd etc on upgrade?
17:44:07 <aba> (or ask an question or whatever)
17:44:10 <keithp> jcristau: it means a huge interruption in how you interact with the machine
17:44:26 <keithp> and may easily break locally installed software or custom hacks in sysvinit
17:44:41 <jcristau> does it?  i haven't changed the way i interact with my machine...
17:44:54 <keithp> You can't just edit files in /etc/init.d and expect things to work
17:45:21 <bdale> so I've moved a number of machines to systemd without negative consequences.  my concerns are therefore more about pushing change on users without having them at least be able to think about and accept the change rather than known difficulties
17:45:33 <keithp> case in point; we have a hacked VPN on a machine that needed DNS to work before it could start; with sysvinit, ordering 'happened' to work. with systemd, it failed.
17:45:39 <aba> I think changing the init systems should be as smooth as possible for those who want to have it done during upgrade.
17:45:52 <bdale> aba: absolutely
17:45:58 <jcristau> we installed insserv on upgrades, that also changed init script ordering
17:45:58 <aba> but I don't think the default answer is "it should be done"
17:46:22 <bdale> it should be easy, it should "just work", but even then something as fundamental as changing the init system seems like it probably deserves an interactive prompt to me
17:46:28 <aba> as example, we didn't replace exim3 with exim4 on upgrades
17:46:30 <keithp> aba: you can't run gnome without it
17:46:32 <jcristau> and users are going to have difficulties if we don't switch to systemd by default because the sysvinit stuff is going to bitrot
17:46:38 <aba> keithp: that's the sad part of it.
17:46:50 <aba> keithp: I haven't yet made up my mind how to deal with that
17:47:05 <bdale> it's pretty easy .. just don't run gnome
17:47:15 <aba> jcristau: I agree we should have an recommendation that people should switch the init provider.
17:47:17 <keithp> jcristau: there's a different issue -- eventually we expect most people to run systemd, but we need to give people a choice about when to switch
17:47:22 <jcristau> aba: you're far more likely to have local config changes to exim than to /etc/init.d/rc
17:47:45 <jcristau> they can choose when they upgrade to jessie
17:47:48 <aba> but breaking mail is far less worse than breaking init.
17:48:04 <aba> otherwise, I agree with keithp here
17:48:06 <jcristau> we're fixing init
17:48:14 <keithp> jcristau: changing is not the same as fixing :-)
17:48:29 <jcristau> changing is not the same as breaking.  aba said breaking.
17:48:51 <dondelelcaro> but it may break things
17:48:53 <keithp> jcristau: we may well break some local config, and init is fairly hard to fix if it really breaks badly
17:48:54 <aba> the potential to breaking.
17:49:02 <jcristau> dondelelcaro: it's a dist upgrade.  of course it will break things.
17:49:26 <bdale> as one simple example, if you have an fstab entry for a device that's not present at boot, sysvinit will whine but continue to boot .. systemd treats it as a dependency failure and stops the boot, right?
17:50:03 <aba> well, e.g. Zugschlus is currently fighting to keep the root hard disk encrypted with systemd
17:50:13 <aba> and it's really ugly if your system cannot decrypt root anymore
17:50:15 <bdale> so, imagine someone with an out-of-date fstab entry trying to do a remote upgrade to jessie and ending up with a system that fails to reboot?
17:51:02 <keithp> I've had constant problems with installing services that come un-configured, and systemd can't start them, so the postinst script fails
17:51:33 <keithp> systemd doesn't (yet) support the usual ways of disabling services in debian
17:51:40 <bdale> those sound like bugs that should get fixed, of course
17:51:44 <keithp> of course
17:51:58 <aba> but people should fail hard on detecting those
17:52:02 <aba> + not
17:52:06 <keithp> I couldn't figure out how to fix them though, because systemd didn't provide any way to use the existing /etc/default/<service> contents
17:52:10 <jcristau> keithp: that sounds like a bug.  not a fundamental problem that means we should leave dist-upgrade out in the cold dark sysvinit ages
17:52:10 <bdale> aba: exactly
17:52:16 <ansgar> aba: Hmm? Encrypted disks should work just fine as long as the initramfs mounts them (which you need for the root fs anyway).
17:52:42 <aba> ansgar: I forgot details, but there is a bug report because one debian-extension is missing
17:52:58 <aba> ansgar: and also it's just an example - I hope this specific one to be fixed before release
17:53:03 <ansgar> aba: Yes, support for keyscripts outside of the initramfs.
17:53:33 <jcristau> surely if you fail to decrypt /, it can't be systemd's fault, systemd isn't started yet
17:53:38 <keithp> so, for jessie, I fear we'll release with bugs of this nature which cause systems to fail to boot with systemd
17:55:11 <aba> looks like we have an agreement in the ctte but not in this #
17:55:37 <dondelelcaro> I guess we just need to draft up some options, and see what the feedback is on this
17:55:45 <dondelelcaro> does someone here currently want to take the lead?
17:56:27 <ansgar> keithp: But will a later upgrade or non-upgrade be less painful? sysvinit->systemd upgrades will probably be less tested for jessie+1.
17:57:11 <aba> ansgar: our recommendation should be that people change the init provider ASAP, and before jessie+1 (unless they want to stick with sysv-init)
17:57:16 <keithp> ansgar: we should expect that as systemd matures that people naturally migrate to it over time, and that we have fewer non-systemd systems by jessie+1
17:57:41 <bdale> and if not, sysvinit->systemd is even more important to get right for jessie+1
17:58:10 <dondelelcaro> and presumably if the support for sysvinit has bitrotted by that point, it would be possible to require systemd before jessie+1 upgrade
17:58:37 <bdale> seems reasonable to me .. this really is all about who's willing to do what work where and when
17:59:03 <jcristau> what's wrong with getting it right this time?
17:59:10 <keithp> jcristau: you have a month
17:59:21 <jcristau> you have 6
17:59:22 <aba> we're not sure enough (yet) that we get it done
18:00:29 <keithp> jcristau: I would like to see the resolution occur before the freeze starts
18:00:53 <dondelelcaro> I guess I can draft up some initial ideas here, and then we can see what sticks or gets shot down
18:00:57 <bdale> so, to the question, I'm too overwhelmed by real life to take lead on this in the next month .. anyone else on the ctte here today want to volunteer to draft something?
18:01:09 <bdale> dondelelcaro: cool
18:01:19 <dondelelcaro> #action dondelelcaro to draft up initial points for sysvinit->systemd automatic upgrade question
18:01:24 <dondelelcaro> #topic #750135 Maintainer of aptitude package
18:01:48 <aba> I fear that was the one I wanted to do something and failed last month
18:01:57 <dondelelcaro> aba: yeah; no worries
18:02:27 <aba> I'll plan to do it this month instead
18:02:30 <dondelelcaro> OK
18:02:39 <dondelelcaro> #actui
18:02:41 <dondelelcaro> err...
18:03:06 <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
18:03:09 <dondelelcaro> okie dokie
18:03:15 <dondelelcaro> #topic Additional Business
18:03:20 <dondelelcaro> anything else that I've missed?
18:03:30 <bdale> not here
18:03:34 <aba> none here
18:03:47 <keithp> I'm off to another meeting...
18:03:50 <aba> except that I try to notice the difference between DST between europe and us better
18:03:57 * aba will go home now
18:04:05 <dondelelcaro> aba: heh. I think we're all still in DST, right?
18:04:06 <dondelelcaro> #endmeeting