Constant disrespect towards fellow developers work, topped with "you can't comprehend simple things". This feels like not being courteous, disrespectably disagreeing, lack of respect on different point of views and insulting. From #gentoo-desktop: [20:49:31] <mgorny> !meta -v gnumeric [20:49:32] <willikins> mgorny: app-office/gnumeric; maintainers: gnome [20:49:32] <willikins> mgorny: (gnome@gentoo.org) eva, leio, pacho, sobhan [20:49:44] <mgorny> ^ wtf is that weird idea that REQUIRED_USE has different impls than deps & co.? [20:52:07] <leio> I don't know what it's about, but it seems gobject-introspection overrides support all python versions, and that part doesn't really care about any sort of USE flags on python or whatnot, but needs installing for all python versions chosen; while python-loader plugin is py2 only [20:52:36] <leio> and this is all written in comments, unless you are asking about something else. [20:53:16] <leio> commit dfc99c2058fa [21:00:26] <mgorny> sure but that doesn't make any sense [21:02:41] <leio> makes sense to me, but I don't know if the REQUIRED_USE bit does [21:26:23] <leio> mgorny: upon review, it looks perfectly correct to me. [21:27:23] <leio> actually you're right in that it probably doesn't need a full python dep with py3 [21:28:19] <leio> or it does if it needs it to get the path and other stuff right for the moduleinto and so on [21:29:37] <leio> it seems like for deps USE=python also ensures python introspection using stuff will work, not just that python-loader is there [21:30:45] <mgorny> so it should also use PYTHON_REQUIRED_USE [21:30:51] <mgorny> otherwise deps make no sense [21:31:41] <leio> no, it can not use PYTHON_REQUIRED_USE. [21:32:35] <leio> or it can, but it's suboptimal, meh [21:32:55] <leio> So, again, there are two things [21:33:01] <leio> there is a python loader plugin, which is enabled via USE=python [21:33:24] <leio> and there is gobject-introspection overrides file, which is always installed for selected python versions [21:33:35] <leio> the python loader plugin at the moment only supports python2 [21:33:42] <leio> thus we only need python2 with USE=python [21:34:09] <leio> The overrides are there to support any python using stuff that wants to use it [21:34:27] <leio> it shouldn't force python into the deptree itself necessarily, it's just a damn .py file dropped in somewhere [21:34:41] <leio> the consumer will make sure to pull in the needed python from its PYTHON_SINGLE_TARGET choice [21:35:03] <leio> and the necessary override via a gnumeric[${PYTHON_USE_DEP}] dep [21:35:57] <leio> the python conditional can be reduced, as you say, but it doesn't matter much [21:36:15] <leio> you can make those only pull in py2 stuff if it makes you feel better [21:36:30] <leio> as long as the overrides install remains working for er chosen PYTHON_TARGETS [21:36:33] <leio> user chosen* [21:37:09] <leio> EvaSDK probably didn't figure out a way on how to achieve that. [21:37:14] <leio> if it's even possible. [21:37:42] <leio> I guess that's just a $(python_gen_useflags -2) too, actually [21:38:21] <leio> but not sure how to do ${PYTHON_DEPS} for py2 only [21:39:22] <leio> I could find out, but I'm not preempting my other work with this thing popping up; I can review a patch and ack or nak [21:46:10] <leio> I guess a $(python_gen_any_dep 'dev-python/pygobject[${PYTHON_USEDEP}]' -2) could do [21:46:35] <leio> with a python_check_deps [00:00:00] - {Day changed to esmaspäev, 22. juuli 2019} [14:05:20] <EvaSDK> leio: yeah, most likely, having python tools with introspection is not super pratical to write proper dependencies for [14:06:06] <EvaSDK> and yes, it looks like I messed up the deps, I'll try to fix that [14:12:35] <mgorny> leio: you're abusing python eclasses [14:12:49] <mgorny> they aren't for 'i use them for some things, and do some things manually' [14:12:57] <mgorny> the whole point of using flags is that you use them for everything [14:13:02] <mgorny> otherwise usedeps can't work properly [14:13:16] <leio> mgorny: I am not, I didn't do that work, and they work fine, just deps are more than necessary. [14:14:37] <EvaSDK> should we split the package to get proper deps ? [14:16:27] <leio> I don't see any problems with the deps? [14:17:47] <leio> I also haven't seen any patches or PRs for what is supposed to improve this [14:17:50] <EvaSDK> they are a bit too much for the loader-plugin indeed [14:18:19] <leio> python? ( $(python_gen_any_dep 'dev-python/pygobject[${PYTHON_USEDEP}]' -2) ) [14:18:21] <leio> maybe? [14:18:34] <leio> with a python_check_deps or whatwasit [14:18:46] <EvaSDK> yes should be fine [14:18:57] <leio> we don't need any deps for the overrides, right? [14:19:09] <leio> moduleinto gi.overrides will work without python, right? [14:28:06] <EvaSDK> technically speaking no deps are required [14:28:16] <EvaSDK> except maybe g-i itself [15:05:38] <mgorny> leio: PYTHON_TARGETS="" emerge -1v gnumeric [15:06:56] <leio> mgorny: yes, what about it? [15:13:35] <leio> working as intended, is what I see. [15:29:53] <mgorny> really? [15:30:12] <mgorny> * No Python implementation selected for the build. Please add one [15:30:12] <mgorny> * of the following values to your PYTHON_TARGETS (in make.conf): [15:30:12] <mgorny> * [15:30:12] <mgorny> * python2_7 python3_5 python3_6 [15:30:12] <mgorny> * ERROR: app-office/gnumeric-1.12.44::gentoo failed (install phase): [15:30:14] <mgorny> * No supported Python implementation in PYTHON_TARGETS. [15:30:18] <mgorny> that's what i see [15:30:28] <mgorny> indicating you didn't use PYTHON_REQUIRED_USE correctly [16:19:18] <leio> mgorny: maybe start with that, instead of a whole circle around deps and whatever else too. Or react to my assertion of "or it does if it needs it to get the path and other stuff right for the moduleinto and so on" or whatever [16:19:24] <leio> PYTHON_REQUIRED_USE is very much correct [16:19:52] <leio> but python_foreach_impl surprisingly refuses to iterate over a zero set, and errors [16:19:55] <leio> that needs to be conditional instead [16:21:50] <leio> python_foreach_impl documentation should be improved to mention that at least one python implementation must be enabled for it, as opposed to how foreach works in programming languages. [16:21:58] <leio> or the restriction lifted [16:22:36] <leio> at least that's what my interpretation now is, still without actually emerging any of it beacuse it's not something on my priority list at this moment. [16:29:33] <mgorny> leio: the whole eclass is expected to work with 1+ implementation [16:29:45] <mgorny> that's why it tells you PYTHON_REQUIRED_USE is obligatory [16:29:51] <mgorny> that's how the whole stack works [16:30:22] <mgorny> so please make gnome packages work the same instead of inventing some confusing special snowflake logic [16:30:45] <leio> sigh [16:31:06] <leio> ok, we can just break it all because no-one but users use the gir overrides anyways; who gives a crap about users [16:31:48] <leio> and refrain from refferring to our volunteer work resulting logic as special snowflake logic [16:32:13] <leio> it is not our fault that the eclass fails to cater for real world needs; except it does, but you call it snowflake logic [16:36:58] <mgorny> no, it is your fault that you can't comprehend simple things and insist on inventing useless complexity and then think you're doing everyone a service
Unlike leio, I don't find wasting everyone's time on endless pointless arguments the best use of my time. So I'll save you all the work and consider myself banned. [15:55:48] <-- mgorny (~quassel@gentoo/developer/mgorny) has left #gentoo-desktop ("http://quassel-irc.org - Chat comfortably. Anywhere.") Enjoy your precious IRC channel where you can spend hours debating how to not follow correct eclass usage and how much hackery you can put into it so that users could suffer.
leio, do you wish proctors to consider further action? (Keep in mind our scope isn't long-standing issues so much as individual incidents. I haven't even read the log so I say this purely hypothetically, but the most we would probably do is issue a short-term all-IRC ban if the offense were serious.) Separately, we do need to have some process around how to validate IRC logs. We can discuss that outside of this bug.
If proctors does not deal with IRC as a whole (including counting infractions across different channels for any repetitive violation counting), then I think that's something to discuss outside of this bug and nothing else to do here - I am an operator of #gentoo-desktop and can deal with that channel in isolation. But interactions and CoC aren't isolated to one single IRC channel, which is why the bug was filed for consideration and public record to usher more respectful attitude from mgorny in the long-run in fear of harder wrist slaps or whatever, which judging from the comment and bug closing here, a self-imposed channel leaving has clearly not achieved. The published policy is a bit unclear about it; it seems first case is a 24-hour ban from "IRC channel", which sounds like just the one where it happened, while the other points don't clarify it and may be taken as a response for "but I haven't violated the CoC over 2 times on THIS channel". I want to stress that as the summary says, this is a _potential_ CoC violation, and I do not want to be actively involved in the decision making if it was or wasn't as I can not be impartial. tl;dr: yes, please consider further action if applicable, and separately clarify the impact of this in a more global sense.
