22:18:41 #startmeeting 22:18:41 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:19:09 #topic Removal of packages from security after p-u removal 22:19:17 this is pending a report from paultag 22:19:26 unfortunately, he doesn't seem to be here 22:19:44 I think Sunday is his no computer day. 22:20:09 ok, so the thing to do here is to email him and ask what the state is 22:20:20 #action mhy to email paultag to ask about the multi-db aware work on dak 22:20:37 I'll do that immediately after the meeting 22:21:08 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 Neil McGovern 22:22:26 I guess? 22:22:34 #pingall Are you here? 22:22:41 <- Still here. 22:22:55 (Should do the trick if mhy does it) 22:23:51 MeetBot: pingall ftp master meetings, who's relevant here speak up 22:23:51 ftp master meetings, who's relevant here speak up 22:23:51 _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 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 sgran skitt Sledge sunweaver ta taffit_s1d thomi tillo warp10 weasel wookey ximion xnox Zhenech zigo zumbi 22:23:51 ftp master meetings, who's relevant here speak up 22:23:58 Maulkin: ↑ that's the syntax ;) 22:24:20 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 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 second item 22:25:44 #topic https://bugs.debian.org/787338 22:25:49 ansgar: did you add that one? 22:26:00 Yes. 22:26:17 * LocutusOfBorg irrelevant 22:26:49 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 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 I think it's badly drafted, but sod it 22:27:40 ansgar: what are your thoughts on it? 22:27:57 I think it implies that modifications are allowed too. 22:28:45 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 Yes, I guess that would be the next (and last?) step for us. 22:29:46 shall I just write the email right now? 22:30:06 Sure, if you volunteer :) 22:30:31 #action mhy to respond to #787338 / #786946 22:30:57 #topic sparc, hurd-i386; and mips64el (bootstrap early, bootstrap often?) 22:31:02 ansgar: can you lead on this whilst I write that email 22:31:09 And the popular issue :) 22:32:00 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 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 let's take sparc first 22:33:45 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 If sparc ever were to come back, it's be sparc64, right? 22:34:01 Also because we still have oldoldstable... 22:34:04 As far as I'm aware, we've had <1 person actually commit to / doing anything with sparc 22:34:32 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 ScottK: yup. 22:34:45 and I agree with ScottK - if it comes back, it'll be sparc64 anyways 22:34:52 Yes, as far as I know there's only XTaran who commits to sparc in some way. 22:34:58 If that's the case, since sparc64 is already on ports, we should just kill sparc. 22:35:15 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 Gah 22:35:32 *consider useful for Debian 22:35:38 I think we've vacillated long enough on this - there's been absolutely *no* real interest in maintaing the port 22:35:45 maintaining even 22:35:56 and we're not running a museum here 22:35:59 Well, it's not only mirror space: 22:36:10 And that ^^ is a better reason :) 22:36:35 It's also accumulating cruft. And the buildds dodn't look to well some days ago (quite a large backlog). 22:37:14 does anyone here present know of any lawful reason why we may not destroy this port? 22:37:30 (I've just realised that phrasing will probably mean nothing to non-UKians) 22:38:11 Maulkin: I assume that you'd consider accepting requests from ports for hardware too? 22:38:20 It's overdue, IMO. 22:38:57 mhy: Sure, if they're things that FTPMasters like. 22:39:11 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 aka: !m68k 22:39:22 mhy: I think we should try to move ports from mini-dak to dak at debconf... 22:39:45 ansgar: is that possible? I thought there were specific requirements (i.e. different dsc's per arch at the moment) 22:39:54 or was there an agreement that could be changed? 22:40:23 mhy: I think that could be changed, i.e. have unstable- and require people to include in the version somewhere. 22:40:53 It would be useful to have aurel32 around ;) 22:40:54 ansgar: and that's still separate to ftp-master.d.o? 22:41:07 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 yeah, he definitely needs to be involved in any real discussion of it 22:41:13 I would keep it seperate, yes. 22:41:21 ScottK: indeed - it's more for hurd-i386 we're talking here I think 22:41:30 ok 22:41:39 OK. 22:41:49 #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 ScottK: powerpcspe or whatever it was? 22:42:24 ansgar: are you happy to take charge of looking at the ports/dak thing at debconf? 22:42:33 That and ppc64. 22:42:42 mhy: Yes, if we have people from ports.d.o. 22:42:43 Not sure what either of them are needed for. 22:42:52 #action ansgar to discuss dak/mini-dak for ports.d.o at debconf with relevant people 22:43:33 ansgar: once sparc goes, do we want to do the assessment of mips64el? 22:44:00 mhy: Which assessment? 22:44:21 Can we decide about mips64el now? 22:44:26 i.e. go through the usual "is it suitable for the archive" assessment. Or has that already been done? 22:45:01 mhy: We already agreed to add it on the 2015-05-17 meeting. 22:45:10 urgh, sorry 22:45:14 in that case 22:45:25 #action mips64el to be bootstrapped once sparc is removed 22:45:52 #topic non-free-firmware component 22:46:04 anyone got some asbestos clothing? 22:46:09 Haha :) 22:46:14 :þ 22:46:21 I think this comes up from time to time so I added it to the list. 22:46:27 for the avoidance of doubt - I'm fully in favour of this 22:46:42 I think that the ability to enable firmware without having to enable all of non-free is a significant win 22:47:05 +1. 22:47:11 * Maulkin nods 22:47:16 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 and of course the maintainers of packages which would move component 22:47:50 (Insert publicity/press too) 22:47:53 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 if we're going to do it this cycle, we should do it soon so that it's well tested 22:48:22 But I was wondering: we currently list the components in the SC... 22:48:34 yeah, that's been the traditional issue I believe 22:48:59 hence, I think it needs a GR 22:49:19 ironically, if we used a different technical means to achieve it which kept it as a single component, we wouldn't 22:50:05 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 I don't think it needs a GR. 22:50:51 It says "a non-free component", not the non-free component. 22:50:53 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 " We have created "contrib" and "non-free" areas in our archive for these works. " 22:51:20 that's pretty explicit afaics 22:51:29 Where is area defined? 22:51:30 Too explicit ;) 22:52:03 ScottK: "area" is the word policy uses for main/contrib/non-free 22:52:06 it'd be easier if the SC just said "We have created areas in our archive..." 22:52:09 but it doesn't 22:52:20 So... Interesting thing. 22:52:29 (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 -o 22:52:37 FTPMatsers are not responsible for contrib/non-free 22:52:43 (Whee!) 22:53:28 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 So, you can do what you want. However, I'd suscpect a discussion on -project or something may be productive. 22:53:52 mhy: yeah, so I see no problems with taht 22:54:01 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 https://lists.debian.org/debian-devel-announce/2012/10/msg00004.html says FTPMatsers are delegated for main only. 22:54:26 who wants to drive this? 22:54:41 I currently don't have too much time, will move in ~1 month... 22:54:56 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 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 Maulkin: I'm not *that* evil 22:56:20 ok, let's come back to it next meeting and see if someone volunteers then 22:56:33 Can we agree that we want it done. 22:56:36 yes 22:56:45 Then if someone volunteers they needn't wait for a meeting to start. 22:56:48 #agreed we want to introduce non-free-firmware but it needs an advocate 22:56:52 ok? 22:57:01 Yes. 22:57:06 Okay. 22:57:12 #topic Any other public business 22:57:29 Given I assume the amount of non-free firmware required will just increase... 22:57:55 agreed, unfortunately 22:58:05 * mhy raises his gavel in the air 22:58:32 #endmeeting