22:18:41 <mhy> #startmeeting
22:18:41 <MeetBot> Meeting started Sun Jun 28 22:18:41 2015 UTC.  The chair is mhy. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:18:41 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:19:09 <mhy> #topic Removal of packages from security after p-u removal
22:19:17 <mhy> this is pending a report from paultag
22:19:26 <mhy> unfortunately, he doesn't seem to be here
22:19:44 <ScottK> I think Sunday is his no computer day.
22:20:09 <mhy> ok, so the thing to do here is to email him and ask what the state is
22:20:20 <mhy> #action mhy to email paultag to ask about the multi-db aware work on dak
22:20:37 <mhy> I'll do that immediately after the meeting
22:21:08 <mhy> ah, hang on, let's just check who is here
22:22:15 * ansgar is here.
22:22:18 * mhy watches tumbleweed go past
22:22:23 <Maulkin> Neil McGovern
22:22:26 <Maulkin> I guess?
22:22:34 <Maulkin> #pingall Are you here?
22:22:41 <ScottK> <- Still here.
22:22:55 <Maulkin> (Should do the trick if mhy does it)
22:23:51 <mapreri> MeetBot: pingall ftp master meetings, who's relevant here speak up
22:23:51 <MeetBot> ftp master meetings, who's relevant here speak up
22:23:51 <MeetBot> _rene_ adrian adsb algernon ansgar aurel32 bremner buxy carnil carnil__ cbmuser Chipzz christoph cjwatson Clint clopez dak debfx DktrKranz dlitz dovber__ enrico enyc_ FBI FloodServ frankie Ganneff gnugr gregoa gusnan hlieberman ijc infinity ivodd jcristau jmccroha1
22:23:51 <MeetBot> jmw Jo-Con-El josch jpleau jvw_ KiBi Laney lazyfrosch_ lfaraone lisandro LocutusOfBorg lucas_ mapreri Maulkin maxy MeetBot mehdi mfv mhy micahg MissionCritical Mithrandir Myon nomadium nthykier olasd olly ondrej pabs pochu Q_ rootbeer ScottK Sebastinas sgnb
22:23:51 <MeetBot> sgran skitt Sledge sunweaver ta taffit_s1d thomi tillo warp10 weasel wookey ximion xnox Zhenech zigo zumbi
22:23:51 <MeetBot> ftp master meetings, who's relevant here speak up
22:23:58 <mapreri> Maulkin: ↑ that's the syntax ;)
22:24:20 <hlieberman> I'm here but not relevant.  Does that count?
22:24:37 * ximion is irrelevant, but here
22:24:58 * pochu is here as well, but irrelevant too :(
22:25:07 <mhy> ok, so on the first topic, I've just written to paultag to ask him if he has any update on it
22:25:41 <mhy> second item
22:25:44 <mhy> #topic https://bugs.debian.org/787338
22:25:49 <mhy> ansgar: did you add that one?
22:26:00 <ansgar> Yes.
22:26:17 * LocutusOfBorg irrelevant
22:26:49 <ansgar> It's about a license used for color profiles. Lintian rejects the files as non-free, but it looks like the license was changed upstream. (Assuming color profiles are copyrightable...)
22:27:09 <mhy> personally, I think that reading the new version as "alterations are allowed" is relatively sensible but I'm willing to be overridden if someone has a good argument
22:27:27 <mhy> I think it's badly drafted, but sod it
22:27:40 <mhy> ansgar: what are your thoughts on it?
22:27:57 <ansgar> I think it implies that modifications are allowed too.
22:28:45 <mhy> ok, so I don't see a problem.  Should one of us follow up to both bugs and ask the lintian maintainers to consider altering the check?
22:29:16 <ansgar> Yes, I guess that would be the next (and last?) step for us.
22:29:46 <mhy> shall I just write the email right now?
22:30:06 <ansgar> Sure, if you volunteer :)
22:30:31 <mhy> #action mhy to respond to #787338 / #786946
22:30:57 <mhy> #topic sparc, hurd-i386; and mips64el (bootstrap early, bootstrap often?)
22:31:02 <mhy> ansgar: can you lead on this whilst I write that email
22:31:09 <ansgar> And the popular issue :)
22:32:00 <ansgar> So, we have two ports that don't look to be releasable now or in stretch: sparc and hurd-i386. We already agreed to remove them from ftp-master.d.o (and possibly move them to ports.d.o).
22:32:41 <ansgar> There is one problem: ports.d.o seems to be overloaded, cf. the thread about the planned sparc removal some time ago on -devel@.
22:33:42 <mhy> let's take sparc first
22:33:45 <ansgar> However we also have a problem with not removing stuff: AIUI some mirrors (not on DSA/d.o hosts) are fairly full and we should ideally drop a port before adding new ones.
22:34:00 <ScottK> If sparc ever were to come back, it's be sparc64, right?
22:34:01 <ansgar> Also because we still have oldoldstable...
22:34:04 <mhy> As far as I'm aware, we've had <1 person actually commit to / doing anything with sparc
22:34:32 <mhy> the question is therefore - does it make sense to use ports.d.o resources on it?  That's not our issue, but maybe we don't want to block removal from ftp-master on it.
22:34:38 <Maulkin> ScottK: yup.
22:34:45 <mhy> and I agree with ScottK - if it comes back, it'll be sparc64 anyways
22:34:52 <ansgar> Yes, as far as I know there's only XTaran who commits to sparc in some way.
22:34:58 <ScottK> If that's the case, since sparc64 is already on ports, we should just kill sparc.
22:35:15 <ansgar> Possibly, yes.
22:35:22 * Maulkin points out that disk space shoudn't be an issue, I'm happy to approve any cash that's needed. However, it depends what FTPMasters cond
22:35:27 <Maulkin> Gah
22:35:32 <Maulkin> *consider useful for Debian
22:35:38 <mhy> I think we've vacillated long enough on this - there's been absolutely *no* real interest in maintaing the port
22:35:45 <mhy> maintaining even
22:35:56 <mhy> and we're not running a museum here
22:35:59 <ansgar> Well, it's not only mirror space:
22:36:10 <Maulkin> And that ^^ is a better reason :)
22:36:35 <ansgar> It's also accumulating cruft. And the buildds dodn't look to well some days ago (quite a large backlog).
22:37:14 <mhy> does anyone here present know of any lawful reason why we may not destroy this port?
22:37:30 <mhy> (I've just realised that phrasing will probably mean nothing to non-UKians)
22:38:11 <mhy> Maulkin: I assume that you'd consider accepting requests from ports for hardware too?
22:38:20 <ScottK> It's overdue, IMO.
22:38:57 <Maulkin> mhy: Sure, if they're things that FTPMasters like.
22:39:11 <mhy> ansgar: I think that as Ganneff isn't here, we should assign him the job of saying sparc is going to be removed then, a few days later, actually doing it
22:39:16 <Maulkin> aka: !m68k
22:39:22 <ansgar> mhy: I think we should try to move ports from mini-dak to dak at debconf...
22:39:45 <mhy> ansgar: is that possible?  I thought there were specific requirements (i.e. different dsc's per arch at the moment)
22:39:54 <mhy> or was there an agreement that could be changed?
22:40:23 <ansgar> mhy: I think that could be changed, i.e. have unstable-<arch> and require people to include <arch> in the version somewhere.
22:40:53 <ansgar> It would be useful to have aurel32 around ;)
22:40:54 <mhy> ansgar: and that's still separate to ftp-master.d.o?
22:41:07 <ScottK> I thought there was some consensus around the idea that sparc didn't need to go to ports.  It can just die.
22:41:10 <mhy> yeah, he definitely needs to be involved in any real discussion of it
22:41:13 <ansgar> I would keep it seperate, yes.
22:41:21 <mhy> ScottK: indeed - it's more for hurd-i386 we're talking here I think
22:41:30 <mhy> ok
22:41:39 <ScottK> OK.
22:41:49 <mhy> #action Ganneff to write to sparc list to say "it's dead Jim" and then to remove it from unstable a couple of days later
22:42:03 * ScottK wonders how many marginally maintained powerpc variants ports really needs.
22:42:19 <ansgar> ScottK: powerpcspe or whatever it was?
22:42:24 <mhy> ansgar: are you happy to take charge of looking at the ports/dak thing at debconf?
22:42:33 <ScottK> That and ppc64.
22:42:42 <ansgar> mhy: Yes, if we have people from ports.d.o.
22:42:43 <ScottK> Not sure what either of them are needed for.
22:42:52 <mhy> #action ansgar to discuss dak/mini-dak for ports.d.o at debconf with relevant people
22:43:33 <mhy> ansgar: once sparc goes, do we want to do the assessment of mips64el?
22:44:00 <ansgar> mhy: Which assessment?
22:44:21 <ScottK> Can we decide about mips64el now?
22:44:26 <mhy> i.e. go through the usual "is it suitable for the archive" assessment.  Or has that already been done?
22:45:01 <ansgar> mhy: We already agreed to add it on the 2015-05-17 meeting.
22:45:10 <mhy> urgh, sorry
22:45:14 <mhy> in that case
22:45:25 <mhy> #action mips64el to be bootstrapped once sparc is removed
22:45:52 <mhy> #topic non-free-firmware component
22:46:04 <mhy> anyone got some asbestos clothing?
22:46:09 <ansgar> Haha :)
22:46:14 <Maulkin> :þ
22:46:21 <ansgar> I think this comes up from time to time so I added it to the list.
22:46:27 <mhy> for the avoidance of doubt - I'm fully in favour of this
22:46:42 <mhy> I think that the ability to enable firmware without having to enable all of non-free is a significant win
22:47:05 <ScottK> +1.
22:47:11 * Maulkin nods
22:47:16 <mhy> as I see it, the people it would affect are: 1) us, 2) the release team, 3) the d-i team, 4) the cd team
22:47:29 <mhy> and of course the maintainers of packages which would move component
22:47:50 <Maulkin> (Insert publicity/press too)
22:47:53 <ansgar> I'm not really against it either: hardware is about the same non-free regardless wheather non-free firmware is included on a chip or uploaded from the host.
22:48:05 <mhy> if we're going to do it this cycle, we should do it soon so that it's well tested
22:48:22 <ansgar> But I was wondering: we currently list the components in the SC...
22:48:34 <mhy> yeah, that's been the traditional issue I believe
22:48:59 <mhy> hence, I think it needs a GR
22:49:19 <mhy> ironically, if we used a different technical means to achieve it which kept it as a single component, we wouldn't
22:50:05 <mhy> I think the way to do this is for someone to draft a GR and explanation.  I'll be honest, I don't have the time or energy for the effort and following of -vote that'll require
22:50:18 <ScottK> I don't think it needs a GR.
22:50:51 <ScottK> It says "a non-free component", not the non-free component.
22:50:53 <mhy> I think that if we don't do it that way (to modify SC 5), there'll be large arguments about it
22:51:03 <mhy> "  We have created "contrib" and "non-free" areas in our archive for these works. "
22:51:20 <mhy> that's pretty explicit afaics
22:51:29 <ScottK> Where is area defined?
22:51:30 <ansgar> Too explicit ;)
22:52:03 <ansgar> ScottK: "area" is the word policy uses for main/contrib/non-free
22:52:06 <mhy> it'd be easier if the SC just said "We have created areas in our archive..."
22:52:09 <mhy> but it doesn't
22:52:20 <Maulkin> So... Interesting thing.
22:52:29 <KiBi> (not speaking for the d-i team as a whole but) I'd be happy to get rid of having too have non-free to get firmware support…
22:52:36 <KiBi> -o
22:52:37 <Maulkin> FTPMatsers are not responsible for contrib/non-free
22:52:43 <Maulkin> (Whee!)
22:53:28 <mhy> Maulkin: not sure that matters for this bit though as we're planning on adding a new area/component not mentioned in the SC
22:53:39 <Maulkin> So, you can do what you want. However, I'd suscpect a discussion on -project or something may be productive.
22:53:52 <Maulkin> mhy: yeah, so I see no problems with taht
22:54:01 <ScottK> I just read the policy bits and I don't think "2.2.3. The non-free archive area" restricts itself to a single component.
22:54:23 <Maulkin> https://lists.debian.org/debian-devel-announce/2012/10/msg00004.html says FTPMatsers are delegated for main only.
22:54:26 <mhy> who wants to drive this?
22:54:41 <ansgar> I currently don't have too much time, will move in ~1 month...
22:54:56 <mhy> creating the component is going to be the easy bit - it's the politics and making sure it gets integrated everywhere which will be harder
22:55:05 * Maulkin nominates Ganneff then
22:55:18 <mhy> if we don't have someone taking responsibility for it, we might have to leave it until someone wants to stand up and do it
22:55:35 <mhy> Maulkin: I'm not *that* evil
22:56:20 <mhy> ok, let's come back to it next meeting and see if someone volunteers then
22:56:33 <ScottK> Can we agree that we want it done.
22:56:36 <mhy> yes
22:56:45 <ScottK> Then if someone volunteers they needn't wait for a meeting to start.
22:56:48 <mhy> #agreed we want to introduce non-free-firmware but it needs an advocate
22:56:52 <mhy> ok?
22:57:01 <ScottK> Yes.
22:57:06 <ansgar> Okay.
22:57:12 <mhy> #topic Any other public business
22:57:29 <ansgar> Given I assume the amount of non-free firmware required will just increase...
22:57:55 <mhy> agreed, unfortunately
22:58:05 * mhy raises his gavel in the air
22:58:32 <mhy> #endmeeting