[00:00:00] - {Day changed to Saturday, 13 June 2020} [01:21:01] zlogene: bug #719212 [01:21:04] what information [01:21:04] kent\n: https://bugs.gentoo.org/719212 "sys-auth/pambase calls cpp directly"; Gentoo Linux, Current packages; RESO, WONT; ago:zlogene [01:21:06] please share [01:21:54] kent\n: I am not aware it should be open and who told you that, we discussed it before inside qa [01:22:03] I asked Soap__ [01:22:09] last I checked, he's QA lead [01:22:36] he literally said it right before I reopened it [01:22:38] last I checked I had a conversation with him about that [01:22:43] nothing changed [01:22:55] was this conversation a decade ago, or in the last hour? [01:23:01] because mine was in the last hour. [01:23:12] like 3 weeks ago [01:23:22] So ... you haven't actually gotten new information. [01:23:45] kent\n: I could not care more here, sorry [01:23:54] you do not need to speak for the qa lead [01:24:07] Just sayin, when I say "QA team lead told me this 30 seconds before I did this", and you say "I have better information", you're calling me a liar. [01:24:11] as far as I saw him in flesh at least twice [01:24:17] he had his own tongue [01:24:20] and head [01:24:33] How you think any of that is relevant to this conversation is beyond me. [01:25:01] I even had Soap__ ack the very statement I put forward before I said it. [01:25:13] kent\n: even qa lead can not step over maintainers' authority [01:25:41] Um. Ok then. [01:25:59] But still, you need to retract your "I have better information", because ... you don't. [01:26:11] You have old information. [01:26:46] QA lead did in fact say it should stay open. You've chosen not to keep it open in spite of their advice. [01:26:50] kent\n: do not worry, we can bitch at each other if needed (I mena Soap__ and me) and see what to do ;) [01:27:12] I mean, its fair enough if there is a good reason not to fix that, but you've not offered any such reason. [01:27:39] But like, that you wear the QA badge as well seems a bit of an insult to QA right now. [01:28:03] Because as-is, your implicit statement is "I don't give a fuck about QA" [01:28:10] kent\n: it is simply preprocessor stuff for if endinf logic, pambase itself compiles nothing [01:28:15] which, maybe you shouldn't be on the QA team if you don't care about QA. [01:28:32] kent\n: it is not about qa [01:28:42] it is all about sanity [01:29:02] Systems without /usr/bin/cpp are broken, and, you can't assume /usr/bin/cpp is what you think it is. [01:29:15] that's a bug :p [01:29:39] kent\n: lots of things are broken without cpp cc string and stuff, the one of them is installed in your system and called gcc [01:30:16] -*- kent\n is aware GCC breaks due to tc-directly, but its not due to GCC not being able to find other parts of GCC [01:30:20] but removing semlynks at a whim is like shooting the leg [01:30:42] its not really "at a whim", its about "simulating different build environments" [01:30:57] some systems won't have it there. [01:31:11] we're just synthesizing those systems using a more common one [01:31:55] and this has potential implications for running prefix systems. [01:32:02] and cross dev. [01:32:19] and *thats* why this bug matters. [01:32:44] it's been settled, this stuff stays [01:32:54] i.e., USE=native-symlinks [01:33:44] Soap__: I'm confused now [01:33:54] you seem to be saying something different to what you said in private. [01:34:16] I completely agree end users shouldn't have USE="-native-symlinks" [01:34:25] but all the same, code that breaks with that configuration needs fixing. [01:34:48] it only shouldn't be fixed, if there's a real problem introduced by doing so. [01:35:02] kent\n: sorry [01:35:05] semantic clash [01:35:09] what I'm saying [01:35:19] USE="-native-symlinks" as an option needs to stay [01:35:33] maybe forced on for extra security [01:36:39] "Forced on" meaning "forced to no-symlinks, or forced to symlink" ? ;p [01:37:00] forced to symlink [01:37:11] the fallout currently is too bad [01:37:14] yeah. And that's fine. [01:37:27] too much will be broken for users who expect working systems as-is. [01:37:41] (qt for instance is the biggest problem right now) [01:38:28] but there needs to be an option to smoke this crap out [01:38:34] since 2012 when tc-directly was created, the problem has been slowly solved in the bigger part, but its at a point now where most things work as expected, and we can commit to cleaning up the mess with relative effectiveness. [01:39:27] I mean hell, I'm making perl stuff work under that configuration, I know the pain. [01:40:06] kent\n: my plan was to make USE="-native-symlinks" obsolete by making all those awful links bash scripts with portage callbacks [01:40:17] But step 1 is "just make it work enough that a global configuration will work, as long as all other packages build under that same configuration" [01:40:27] [[ -z ${some_portage_var} ]] && echo "using naughty links" [01:40:38] Step 2 is the harder part, where you try to make it work with a different potential CC for every package. [01:41:20] Step 1, is close to being fixed, and I'm not asking for people to try solve Step 2 juusst yet ;p [01:44:20] zlogene: also, there's no harm in leaving the "depends on" links in place, you can still have a bug "resolved" with that. It just helps people on the cited bug track down things. [01:44:49] so whatever your opinion is as maintainer on fixing it is, removing that link is still detrimental [01:46:16] kent\n: well, as long as David turned on qa bdfl it is not that much you gaing but having it blocked [01:46:39] s/but/by/ [01:47:47] It just means that people who look at the bug, will be able to easily see the connected bugs. Which they are, absolutely. [01:48:39] and if QA decides, "yes, this must be fixed", then .... its on them to reopen it, and/or, do it themselves, which last I checked, QA are allowed to do. [01:58:47] kent\n I have reopened this one [02:00:26] thanks. And I don't demand it get fixed by you, or anyone, overnight. But like, until it ceases to be a problem, it should be an open bug, if, for no reason other than, so other people who hit the bug in testing can easily search for it [02:00:55] (otherwise you will get the bug re-reported over and over again in different words ) [02:02:09] perhaps, a feature will land in portage that makes it go away some day, and when that day comes, the bug can be closed without further effort. [02:02:22] kent\n: I do not think this bug gonna recieve fix at all, becsuse i gonna kill current build system eventually [02:02:35] that's also fine. [02:02:53] no idea why Diego picked cpp at all [02:03:21] If a future incarnation of the ebuild doesn't have this issue, due to a toolchaining replacement, that also "fixes" the bug, even though its a different mechanism [02:03:57] lol. Diego also made the tc-directly bug. lol [02:04:45] kent\n as I said, noone notices what pambase calls during its install, everybody gonna notice if i break the configs ;p [02:26:31] seriously [02:26:37] CPP has a general macro language [02:26:45] has to be one of the most asinine things diego did [02:27:23] as [02:32:51] as: command not found' [02:32:53] -*- kent\n hides