18:59:36 #startmeeting 18:59:36 Meeting started Wed Nov 20 18:59:36 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:42 #topic Roll Call 18:59:49 Is anybody out there? 18:59:59 * gwolf moos 19:00:46 * ntyni waves 19:01:06 Tollef Fog Heen 19:01:14 Didier Raboud, barely present 19:01:22 Philip Hands 19:01:29 Margarita Manterola 19:01:30 Niko Tyni 19:01:31 Gunnar Wolf, for ~40min 19:02:19 bremner said he'd be late 19:02:48 Alright, let's move on... 19:03:04 #topic Review of previous meetings AIs 19:03:19 I have failed at my task, which was sending an email to d-d-a 19:03:27 I should be able to do this before the end of this week. 19:04:27 I actually managed to email -devel about the module/interpreter dependencies thing 19:05:02 thread starts at https://lists.debian.org/debian-devel/2019/11/msg00212.html 19:05:56 this last couple of weeks I haven't been able to read d-devel at all ☹ 19:06:21 I didn't claim I read it either :) 19:06:46 * marga reading the thread 19:07:25 I shall look at it later today. This thread, at least. 19:07:40 Ok, there isn't a lot there. Mostly people giving a few extra pointers of other languages 19:07:45 right 19:08:08 it seems to point in the direction of modules not pulling in interpreters from my reading of it, though 19:08:15 only got around to it a few days ago so not concluded yet 19:08:21 Mithrandir: agreed 19:08:23 Right. Mostly this issue is regarding a corner-ish case... 19:08:38 so people will probably say "don't bug me, but we do XXXXXXX" 19:10:24 Alright. Thanks Niko for taking care of this! 19:10:41 Let's move on to the bug discussion to figure out what to do next 19:10:50 #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment 19:11:36 The point of the thread that Niko started was to ask for input regarding the possibility of not having to depend on ruby and nodejs for the library thing 19:12:26 Terceiro, from the Ruby side, mentions that they mostly didn't drop the interpreter dependency in ruby "due to inertia" 19:13:08 indeed 19:13:25 I don't think anybody chimed in from the nodejs part 19:14:06 AIUI, the issue is much more important even for nodejs, as it can be used to serve the libraries that are run $elsewhere... 19:14:25 so having an interpreter is far from needed in order to properly use the libraries 19:14:59 (sorry I'm late) 19:15:22 Hey there Simon! 19:15:46 a little while ago I spoke to a ftp team member about the specific cases mentioned in #934948 and he said he would check with other team members whether the right decisions had been made in those cases 19:17:04 So, I think each interpreted language is slightly different. As Gunnar mentions, javascript libraries can be used to run on the browser and thus the interpreter isn't at all needed in that case. Some interpreted languages ship the standard library together with the interpreter, some separate. The meaning of the standard library also differs from language to language... So, I don't think we can make a general statement about what this 19:17:05 dependencies should be. 19:17:54 something that did come up in my conversation with the ftp team member I am deliberately not naming is the design principle of: 19:18:16 if it's a library for use by JS/Ruby/Python/etc., package it like a libary 19:18:50 if it's an executable to be run by scripts, interactively etc. without needing to know or care about its implementation language, package it like an executable 19:18:58 and this might imply a split 19:19:22 But aren't both packages involved libraries? (one nodejs and one ruby) 19:20:03 I mentioned src:tap.py, which is one of my own packages, and he thought it's correct that tappy.deb (executable) and python3-tap.deb (library) are separate for that reason 19:20:18 in the case of #934948 it's less clear-cut 19:20:59 one of the packages happens to contain an executable, but it wasn't clear to us what that executable is for, and whether it's a general-purpose utility, or an equivalent of sdl2-config (which is correctly in the -dev package), or what 19:22:33 right, many libraries include executables that are example or testing items, and should not be forced to DEPEND on the interpreter 19:24:29 again, I think part of the problem with #934948 is that it still isn't clear to me what Pirate wants from us 19:24:50 Advice? 19:25:55 advice on whether to open a GR proposing overruling the ftp team? 19:26:19 He is asking our opinion to use it as a means for the ftp-masters to change their decision 19:26:31 the impression he gives to me is that he wants a very clear legalistic ruling in which to start hunting for loopholes, but I suspect that is at least partly due to the way I'm reading what he writes 19:26:56 Yeah, on second read I think he wants support for his case 19:26:59 (i.e. we can decide this without overruling a delegate - we cannot make ftp-masters obey our reasoning) 19:27:13 but I think we _do_ support his viewpoint... right? :-} 19:27:50 in my case: "yes ish, but with caveats" 19:28:05 Well, my position is that there was a lot of miscommunication and that the involved people should actually talk respectfully to each other 19:28:17 I'm pretty sure that if that were to happen, the problem would be resolved 19:28:24 But we can't force that to happen from the TC 19:28:47 marga: Completely agree with you. But he is asking for our opinion 19:29:18 clearly Praveen was angry when he wrote the bug report... but forcing this through a GR would be ... the worst possible outcome :-\ 19:29:35 Well, that's my opinion. And yes, I agree that going through a GR is not the right avenue. 19:30:26 To me, it does seem to me that the package could *recommend* both ruby and nodejs instead of depending on them... Given that there doesn't seem to be official guidance for ruby modules, and the ruby team even considered dropping the deps as the default and didn't do it because of inertia. But then there's the question about the ruby libraries that the package does depend on, which should also move to recommending the interpreter. 19:30:58 FWIW we could read it like "he is threatening us with a GR"... I'd rather not, I'd rather see we answer to him politely, but reminding the limits of action for a TC answer 19:32:08 looks like there's at least one recursive dependency to a binary Ruby module which needs a Depends: libruby2.5 which probably takes away much of the point of changing the others to recommendations 19:32:33 I think the wider context might be that if libraries are very small, it might make sense to combine multiple related libraries into a larger package, at which point splitting that package by language might be more acceptable because the split parts will be less tiny and less numerous? 19:32:59 Sure, but this is all in a package by package basis 19:33:10 I don't think there's a general ruling that we can offer here 19:33:23 I can poke the ftp team member I spoke to and see whether they have discussed this specific case if that would help? 19:33:24 BTW just out of interest, did we ever find out if there was a use case where being forced to needlessly install a couple of interpreters actually manages to upset or inconvenience anyone? 19:33:28 smcv: Oh, the nodejs-inflicted pain? :-P 19:33:49 fil: I was wondering the same 19:34:03 fil: Well, if you were to prepare an embedded image where space was at a premium... 19:34:12 but I don't think that has been brought up... 19:34:36 ... then some carefully-deployed rm -f is potentially your friend? 19:35:16 gwolf: and you might just add the the expulsion of the interpreters to the special-casing you're doing anyway, if you're very short of space 19:35:57 Yeah... 19:36:27 ditto; I can see it being the case in some specialised use cases, but nearly everywhere, space is cheap nowadays. 19:36:42 Need to get 15.5 MB of archives. 19:36:42 After this operation, 62.0 MB of additional disk space will be used. 19:36:46 that's for the ruby parts 19:37:23 yeah, it's not _nothing_ but only very specialized cases would care. 19:37:46 So... How do we move on? 19:37:55 and is there any chance of someone wanting _these_ packages on a minimal embedded system? 19:38:23 fil: There's always Someone Very Special™ ready to break your assumptions :-Þ 19:38:33 We can tell Pirate to: A) let it go B) Move the ruby dependencies to recommends and then let it go C) try to actually talk with the ftp-masters and see if they can come to an agreement... 19:39:10 I'm not saying that allowing minimal installs is unimportant, but if the usecase is largely fictional, then this seems like a lot of effort for little real benefit 19:39:11 marga: Given this is a formal question for us, I think we need to explicitly reply 19:39:35 sorry if I'm no understanding your point - it seems _privately_ approaching and that? 19:39:45 no, no, I meant reply to the bug 19:40:07 And we can actually include all 3 options. 19:40:10 I think we should issue our opinion, mostly B. 19:40:28 That would mean, "we agree with the submitter, but it's up to ftp-masters to actually decide" 19:40:48 seems fair 19:43:00 I think I'd still include something along the lines of "The Technical Committee still encourages you to try to talk to the ftp-master team and come to an agreement regarding this specific package"... Although I'm not too happy about that wording 19:43:09 Sorry, now I'm leaving you... I have to run. 19:44:09 marga: I agree it would be nice to include something like that 19:45:18 Ok, we are 45 minutes into this meeting, we should try to decide on something and move on... 19:45:37 smcv, as you are the one that's been following this the closest... What do you think should be the right move? 19:45:38 would people be in favour of putting TC authority behind a preamble that says "there are a bunch of design principles, they partially contradict, it's a trade-off"? 19:46:04 so something like 19:47:18 1. (approximately the design principles I gave in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#12), but these are sometimes in conflict, and when they are, it's up to the maintainer and ftp team to find the least bad trade-off 19:49:51 2. we encourage maintainers and the ftp team to communicate respectfully, and in particular acknowledge valid points even if they are outweighed by a higher-priority consideration 19:50:03 (needs better wording but hopefully you get the idea) 19:50:16 Yeah, this goes along what I was saying 19:50:54 sure 19:50:55 3. in the specific case of src:ruby-task-list providing both a Ruby library and a Javascript library, we think ((A) or (B) or something else) 19:50:56 sounds good to me 19:51:03 sgtm too 19:51:31 I can try to write a better version of (1) and (2) 19:51:39 Yeah, sgtm 19:51:50 And you could ask here for people to chime in regarding the wording 19:51:51 I'm not sure what I think the best answer is for (3) 19:51:58 (through a pad or wahtever) 19:53:27 ok, action me to write a draft of (1) and (2) at least 19:54:38 #action smcv to draft a reply noting that there can be a tradeoff that's up to the maintainer, that maintainers should try to respectfully communicate with ftp-master to solve conflicts, and some specific advice for this issue 19:54:44 maybe (3) should itself be "here are some options to consider, and if the maintainer and the ftp team *really* *really* can't agree, the TC would suggest foo" 19:54:55 Sure 19:55:34 So, quickly, let's jump into the bug that got unarchived 19:55:37 #topic #932795 How to handle FTBFS bugs in release architectures 19:55:52 We had closed this bug and it was archived, but Santiago replied and it got unarchived 19:56:24 I'm not sure there's anything to be done, but I wanted to raise it in case anybody had opinions 19:56:44 s/Santiago replied and it got unarchived/Santiago unarchived it to reply/ FWIW 19:57:45 Ah, ok, yes 19:57:49 I wasn't sure how this worked 19:58:01 I note that he mentions that there are about 50 bugs each way (fail on 1, but not 2 CPUs, or vice versa) 19:58:08 Right 19:58:37 Which I think both fall into the category of "should be fixed but not keep things out of testing" 19:59:14 so, important? 19:59:34 Yeah, FMPOV 19:59:38 ye 19:59:39 +s 19:59:55 I don't think we should recommend any particular severity, tbh. 20:00:12 not sure I see much point in continuing the discussion though 20:00:34 (I agree with recommending !RC, but I think we should leave it to the maintainer/RT to decide.) 20:00:35 He's arguing that they shouldn't be simply be downgraded to non RC, and should rather require someone to actually make a case for an e.g. buster-ignore tag 20:00:45 ntyni: agreed. 20:01:01 given the amount of disagreeing with santiago I've done on that bug, if it is felt to be important to respond, I would very much appreciate not being the one to do so again 20:01:13 I've said everything that I think needs saying 20:01:31 smcv: thanks for that 20:01:54 (for your past participation on the bug, that is) 20:02:13 fil: the description of serious talks about "in the maintainer's or release manager's opinion", so I think it's ok for a maintainer to downgrade; the submitter can appeal to the RT if they want. 20:02:31 but yeah, I think we should re-close the bug with no action. 20:02:36 Ok, so, does anybody think we should reply? 20:02:48 The bug is still closed, and it will get auto-archived in a month... I think. 20:02:51 it's closed already, will be rearchived in time 20:03:09 sure -- I was just summarising -- I'm not particularly persuaded by his argument 20:03:25 ah, ok. I guess somebody can reply with a "thank you for providing the numbers". 20:03:53 Ok, I can do that. 20:04:07 #action Marga to reply thanking Santiago for providing the numbers 20:04:32 And we're over time... So, I'll just end here, unless someone has something extremely urgent? 20:05:27 nothing from me 20:05:28 one last link-drop: 20:05:29 https://lists.debian.org/debian-release/2019/09/msg00475.html 20:05:37 is relevant to the single-CPU-FTBFS thing 20:06:14 in particular "we consider 20:06:17 ourselves the right party for case-by-case judgment of FTBFS bugs" 20:06:21 (we = release team there) 20:06:22 and 20:06:29 "we don't consider 20:06:30 FTBFS on single CPU machines RC by default" 20:06:53 Cool, thanks! 20:07:06 #endmeeting