Re: [gentoo-dev] GPG key refresh
On 12/16/20 03:01, Michał Górny wrote: > On Tue, 2020-12-15 at 23:37 -0500, Aaron W. Swenson wrote: >> On 2020-12-15 11:16, Michael Orlitzky wrote: >>> On 12/15/20 11:11 AM, Thomas Deutschmann wrote: What do you mean exactly? For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer synchronizes with any other pool. >>> "The Gentoo developer tooling explicitly checks the Gentoo >>> keyserver >>> pool with a much higher frequency" strongly implies that we check >>> the >>> non-Gentoo pools with a non-zero frequency. >>> >>> >> >> I'm with Michael on this. I've recently experienced this issue myself >> as the >> instruction to upload the key to the Gentoo keyserver is separate >> from the >> GLEP63[1] document. It doesn't matter that the step is documented if >> the Holy >> Tome GLEP63 doesn't mention it. What hint would I have to look for a >> supplemental document to provide that specific step? >> >> According to GLEP 63, uploading to the SKS keyserver is a >> requirement. >> However, it fails to specify which SKS keyserver. In fact, neither >> "SKS" nor >> "keyserver" are defined in GLEP63. Ergo, the natural interpretation >> is *anything* >> that's called an SKS keyserver will satisfy the requirement. As long >> as the >> developer can submit the key, the requirement is met. >> >> Additionally, the supplemental document[2] doesn't say developers >> must upload >> via an internal host, but that devs should upload to both SKS and the >> Gentoo >> keyserver. Yes, it says the Gentoo keyserver is currently restricted >> to syncing >> with "authorized Gentoo hosts", but that's a nonsense phrase and >> unhelpful. It >> assumes I know what the authorized Gentoo hosts are. It doesn't >> clearly state >> what they are. It kind of hints that it will pull from SKS >> eventually, but it >> could take a long time. >> >> I understand we temporarily stopped syncing with the public keyserver >> out of an >> overabundance of caution. However, that shouldn't have been done >> without >> updating every official Gentoo resource regarding how devs should >> handle their >> keys, which as far as I know is only two documents[1,2]. A whopping 2 >> documents. >> >> This new (I know it's been around for a year but that doesn't make it >> any less >> new), stricter requirement, should be **explicitly** stated in >> GLEP63, properly >> referencing the justification[3], and linking to the infra >> supplemental >> document. The infra supplemental document needs to then use the >> phrase "must" in >> place of "should" when informing readers to upload to two different >> locations. > > ...and what have you done to resolve the problem, except for making > oververbose complaints and demands in middle of some random thread? > Discuss it, which is more than you have done here. There is no need to berate signal because you feel like making noise. Formulating and discussing ways to fix problems before actually fixing them helps to reduce effort wasted on rebuilding old solutions which have failed for whatever reason. In this case documentation needs to be updated, discussing the appropriate manner in which to update which documentation seems to be more grounds for engagement than recrimination. On the subject of updating the documentation, the proposal seems generally sound; do you have any constructive criticism of it?
Re: [gentoo-dev] unverifiable GPG keys for @gentoo.org members
On 05/12/20 01:24, Michał Górny wrote: > W dniu pon, 11.05.2020 o godzinie 20∶20 -0400, użytkownik Aisha Tammy > napisał: >> Hi devs@, >> Seems like for some reason the gentoo.org does not publish the >> gpg public keys of the senders, even though it is signed correctly. > > Why do you claim that? How did you verify it? Why are you jumping > straight to passive-aggressive accusations without asking nicely first? > That last question could very much be asked of you because of your asking it of them. They needed information, at least some of which you did give, not clutching of pearls and baseless protestations of offense. >> >> Just wanted to know why the devs are required to use gpg keys, glep63 >> [1] >> but even when the server has the public keys, they aren't published >> properly. >> >> From a proper security perspective, I would have though something >> like WKD[2] would have been implemented on the server side for >> automated >> authentication. > > WKD is implemented and I don't know a single case where it wouldn't > work. If it doesn't work for you, then I dare say it's more likely to > be a problem with your setup. However, if it's a problem on our end, > I'd really appreciate a bug report before calling us retarded. > Given that they did not call anyone any names, retarded or otherwise, one could make the case that you are making a personal attack against them by smearing them and their postings; at best that hurts your argument as a supposedly affronted party. So, please, try to not construct offense out of whole cloth to be performatively perturbed at; it serves no purpose beyond making the lists less useful due to increased noise and making social norms in Gentoo (especially on the lists) that much less congenial. > In fact, the link you've posted actually lists gentoo.org as one > of the few organizations implementing WKD. > >> >> Maybe I am missing something about how to verify the keys of the >> maintainers >> who are sending announcements but it irks me a teensy bit when i have >> signed >> mails and I can't ~~trust~~ verify the signatures. >> >> > > You are missing that WKD does not provide authentication, and if it > were, it would be considered thoroughly insecure. Authentication > in OpenPGP is generally provided via web of trust. For Gentoo > developers, you can also use our Authority Keys [3,4,5]. > >> >> [1] >> https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys >> [2] https://wiki.gnupg.org/WKD > > [3] https://www.gentoo.org/downloads/signatures/ > [4] https://www.gentoo.org/glep/glep-0079.html > [5] https://wiki.gentoo.org/wiki/Project:Infrastructure/Authority_Keys > >
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On 02/18/20 02:36, Matt Turner wrote: > On Mon, Feb 17, 2020 at 11:47 PM desultory wrote: >> > > You've got a particular knack for this kind of argumentative nonsense. > > While I will gladly accept that post being described as "argumentative", as after all I am very much interested in reading actual arguments sufficient to convince me that my impressions and the opinions derived therefrom are incorrect; I do take issue with it being described as "nonsense". So, I put to you the simple question: how, exactly, is it nonsense? I extrapolated from your own activities and your own statements about your own activities. If you don't like the impressions thus derived it might do you well to address the sources of those impressions instead of dismissing them as nonsense. Or, are you telling me that your own statements are nonsense and your actions nonsensical and thus impressions derived from them are nonsense? That in itself produces a rather strong impression.
Re: [gentoo-dev] Changes made by acct-* ebuilds
On 02/13/20 03:10, Michał Górny wrote: > On Wed, 2020-02-12 at 23:03 -0800, Alec Warner wrote: >> On Wed, Feb 12, 2020 at 9:59 PM Michał Górny wrote: >> >>> On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote: Hi, thank you for bringing this to the list. I have the same experience which is the reason why I haven't migrated most of my packages yet (which is not a good move because I also didn't post the problem to the list like I wanted *yet*, I only talked to people via private mail, chat or at FOSDEM about that and was working on a proposal I wanted to show next week when I am hopefully healthy again). >>> >>> In other words, instead of bringing the problem up to the person who >>> created the GLEP and the eclasses and/or community at large, you've been >>> conspiring behind their back. Yes, that's really the procommunity >>> attitude we expect from Council members. Thanks for showing it again. >>> >> >> This is a bit of a double standard. Either people are 'conspiring behind >> your back' or they 'are gathering data for a counterproposal.' There is no >> need to paint a negative narrative here. >> > > Yes, I certainly do have a reason to assume positive from someone who > apparently mounts a counterproposal without bothering to consider > the original reasons. > Given that we have already established that you cannot distinguish between technical feedback and personal attacks, consider this a "teachable moment". You have not been personally attacked in this thread. Someone has posted commentary critical of something you were involved in. Yes, you expended significant time and effort in that project but it is the fruits of the project, not your personal integrity, competence, sanity, nor preference in ice cream that are being called into question. There is no call for smearing the other party, just conversing with them, evaluating their arguments as they evaluate yours and reaching a mutual understanding of each other's perspectives and issues as they relate to the project at hand. If they have concerns which the project does not adequately address in its current form, the implementation can be improved; if their concerns are adequately addressed by an improved understanding of the implementation as it exists now, then at the least you will have discovered where the documentation could be improved. Note that I am not in any way opining upon the project or implementation itself as that is immaterial to my point.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On 02/14/20 11:14, Matt Turner wrote: > On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth) wrote: >> In this instance, at least two people (myself included) have drawn an >> impression that led them to voice their concern in some way (I'm unsure if >> mpagano was voicing concern or just agreeing with the general concept). Maybe >> we're the only ones. Maybe not. > > What do you think the threshold should be? If one person objects, > should ComRel cease and desist? Two? Should we have a Gentoo-wide > vote? > How many people objecting to your handling of a situation would it take for you to consider that you might have handled it in a less than ideal manner? Two? Three? Do we need unanimous declaration by all holders of @gentoo.org e-mail addresses, including yourself, before you even consider it? > I don't have the highest opinion of ComRel and I'm a member, but maybe > you could let us do our jobs? > > Given that I am not your therapist, I am going to consider this comment from an objective perspective not en emotional one. Given that you "don't have the highest opinion of ComRel", that implies rather strongly that you do not consider ComRel to be competent. Given that you are still a member, that implies that either (1) you consider yourself to not be the least competent member of ComRel (presumably of basic competence), or (2) you are a member specifically to attempt to gain such competence. In the former case, perhaps consider undertaking training of those less competent than you (thereby improving your opinion of ComRel as a whole), in the latter do kindly avoid undertaking actions that you are not competent in. As for the "maybe you could let us do our jobs?" part of that comment, this appears to be a distinctly worrying trend among "special" projects in Gentoo. Proctors now openly refuse to actually undertake their mandate because they face the existential horror of negative feedback when they make outlandishly perverse claims. ComRel now insists, by implication, that while it is by the description of at least one member openly incompetent, feedback is unwelcome at best. Even QA has made similar sorts of empty appeals to their own authority, while also refusing to actually argue their case. None of these should be at all acceptable, yet somehow this nonsense is largely left uncontested for reasons that escape me entirely, If you cannot adequately "do [y]our job", consider that perhaps you should not be doing it in the first place.
Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind
On 10/29/19 19:08, Patrick McLean wrote: > On Tue, 29 Oct 2019 23:03:15 + > James Le Cuirot wrote: > >> On Tue, 29 Oct 2019 11:23:20 -0700 >> Patrick McLean wrote: >> >>> On Tue, 29 Oct 2019 16:10:37 +0100 >>> Andreas Sturmlechner wrote: >>> Anyone else who thinks this should not be restricted to just desktop profiles? >>> >>> I am not aware of any use cases for elogind/consolekit on servers, >>> it's really for machines where you have to distinguish between >>> someone connecting remotely and someone physically using a >>> keyboard/mouse connected to the machine. >> >> I switched from consolekit to elogind on my normally headless ARM box. >> It runs XMMS2 and outputs through PulseAudio. Under consolekit, my >> user's /var/run directory would disappear after a while, taking the >> pulse socket with it. Under elogind, I was able to set my user to >> "linger", which fixed the issue. It's not a typical use case but yeah, >> they do have uses outside of desktop. > > Which sounds like perfect for a local setup, probably not something > that should be in a generic profile. > > > The bulk of the proposed news item is apropos packages and the reason that the profiles are changing, not actually profile specific considerations; and running a desktop environment hardly requires running a desktop profile. Given that the news is largely in regards to specific packages it seems logical that it would more fully reach the user base affected by the causal changes were it simply directed to those with the package being deprecated installed (as indicated in the proposed news item) without regard for what profile they are using. Beyond that, I'm not aware of any advantages to limiting it to desktop profiles despite the direct cause of the news item being a transition in the profiles; while targeting it more generally does provide the benefit of reminding users who are not using a desktop profile to at least consider following suit prior to last rites on a package that they have installed thereby providing a better user experience on the whole.
Re: [gentoo-dev] The demotivating process of contributing to devmanual
On 10/18/19 01:53, Matt Turner wrote: > On Thu, Oct 17, 2019 at 9:38 PM desultory wrote: >> > > Since the thread seemed to have already wrapped up with a positive > resolution, I question why you responded in the way you did. > > To quote the original post: On 10/15/19 16:35, Michał Górny wrote: > This time I'm saying enough.
Re: [gentoo-dev] The demotivating process of contributing to devmanual
On 10/15/19 16:35, Michał Górny wrote: > Hello, everyone. > > I'd like to highlight a major problem with devmanual. For a basic > policy & developer documentation thingie, it's quality is so-so at best. > A lot of stuff is missing, lots of things are outdated or even > incorrect. Not many people are contributing, and those who try quickly > resign. > Which neatly ignores the historical reasons for it having ended up in that state. Developer documentation had previously bee spread rather more broadly, but services got shut down without all of that documentation being migrated into the remaining service(s). As a supposedly omnibus resource, the developer manual has yet to come close to recovering the breadth of what had been available online and even when the services were shuffled around it was lagging in currency. In short, this is not a new problem. Hence the tendency toward rapid burnout in those even considering fixing it all, let alone maintaining its currency during the process. To be explicit, I am in no way claiming that the services in question needed to be retained forever despite infra having decided to shut them down. I am just noting that having, at the time, multiple "primary source" references was part of the setup for things evolving in the manner in which they did. The moral of the story is not that it was somehow wrong to shut down services which were overly maintenance intensive, but that data portability is important to data continuity and that having enough people willing to maintain documentation over time is important for the health of a project over time. > I have been very patient with this. However, my pressure has just risen > dangerously, and I think it's time to lay my frustration down on this > list. Maybe this will finally change something because my supplications > were unsuccessful so far. > Just as a general note, frustration on the part of one party does not in any way necessitate action on the part of another party. Sometimes frustration is justified. Only rarely is public ranting a better solution than actually discussing the issues at hand with those responsible for handling them. Far too often both get neglected in favor of individuals indulging in their own personal catharsis. > So a typical case of contributing to devmanual looks like this: > > 1. You put an effort to make a good patch. You submit it and wait. > > 2. Usually, after 2 weeks you get review, with a lot of grammar > nitpicks. I get that having nice pretty words is important, so I apply > them. If I have also tried to keep a nice history, I end up putting > the requested changes in appropriate commits. This usually takes > as much time as the original change but sure, worth it. > > 3. If you're unlucky, you're told that you're using the wrong formatting > style. For example, you used the style of the preceding section which > is wrong. Or tyle style from style document which is apparently also > wrong [1]. But don't worry, after having to reformat a major change > twice you learn to remember the style acceptable by current devmanual > project people. > > 4. You wait again. With some luck, this time less than two weeks. Then > you learn you need to do more grammar changes. Possibly to stuff you've > already changed before. Fixing already takes more time than starting > from scratch. > > 5. Eventually, you discover you can't even properly merge the changes > back into your commits because the devmanual developers made you start > changing stuff you didn't touch in the first place. > > Then you look at 'git log' and top your frustration with the fact that > person who just made you waste another total of 4 hours to > unsuccessfully try to update an important document so that it doesn't > list practices we don't do for 10+ years, has not made a single change > himself in 2 years! > > No offense intended. I understand people don't have much time. I can > understand that people can't even find time to review stuff and get it > merged within less than a month. But if you don't have time yourself, > why do you keep behaving like everyone else must have tons of free time > to get everything perfect for you? > > I'm going to be blunt here. If you applied suggested changes yourself > instead of writing them for me to do, you'd save a lot of time for us > both. Or if you just merged it and fixed it yourself afterwards. > Or accepted the fact that everything doesn't have to be perfect, > and reasonably correct documentation with imperfect grammar is better > than obsolete useless documentation that also has imperfect grammar just > because it was written before your time. > So, to be blunt, code review is a pointless exercise because the reviewer could fix things faster themselves. Broken code is fine, syntactically and semantically invalid code is fine, it can be fixed after it has broken users systems and lost their data. It is more convenient for the coder that way, no pesky worri
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 07/25/19 04:14, Kent Fredric wrote: > On Thu, 25 Jul 2019 00:10:49 -0400 > desultory wrote: > >> The user-side effects pf the proposal in question, were it to become >> policy, would be that anyone seeking to not install what is presently >> optional documentation would either be: >> (1) wasting build time and space (and, depending on implementation, >> dependencies) on their build system (potentially masking the files from >> being installed); >> (2) wasting the space in their installed image(s) (if they did not mask >> the files which would not currently be installed anyway); or >> (3) wasting their own time working around what the developers would be >> required by policy to implement by repackaging the software themselves >> to avoid the time and space drawbacks (though this would generally be >> expected to be a rather exceptional case, as it would be relatively >> extreme to avoid what would be a distfile and some file masking from the >> user side). > > Those concerns as per current policy is unrelated to the > dependency-control-of-USE issue presented here. > > Its already established not to use a USE flag to toggle building of man > pages if it doesn't require additional dependencies. > > These are _man_ pages we're talking about, not general purpose > documentation. > > End users who don't like man pages are encouraged to use the relevant > FEATURES to strip them from the installed image, or use INSTALL_MASK or > something. ( FEATURES=noman ) > > The GOAL here is to provide man pages in *all* circumstances, and, if > additional dependencies are required to build them, to ALWAYS install > them, or NEVER install them, and then, find a secondary way to obtain > man pages (prebuilt) > > The Total Cost of man pages as pure files on the target system is tiny, > and has practically no risk with regards to complexity. > > But the cost of *dependencies* has risk, and can inflate to complexity, > causing much more real problems for more users than a few kb of .1.bz2 > files. > > Hence, why we gate them with USE flags: Because it provides an out for > that complexity ( at the cost of giving a different kind of complexity, > and a reduction in utility if somebody has to opt-out to get around > that initial complexity ) > So, we more or less concur on those points, or are you attempting to convey some other meaning by restating points? > And hence why the counter-proposal to USE flags to solve that > complexity a different way is "prebuild them yourself and ship > them" ( as that eliminates all the dependency complexity and USE flag > complexity user side, while also giving them the man pages -> Quality ) > > Just the current mechanisms for this counter-proposal shift that > inescapable complexity to a place where it becomes harder to manage in > a standardized way. > Are you referring to a QA mandate to package or build man pages, regardless as a counter proposal to the status quo? If so, why? It is a proposal; the status quo is, at the risk of redundancy, the present state of things. > And I don't think shifting this complexity to maintainers is the right > step, even though I want the same deliverables. > > That's why I'd rather a way to shift this complexity to a build > service, ... albeit, it introduces some complexity of its own with the > building and distribution of these man pages. > As I have noted twice before in discussion of this proposal, such a build service once existed, and indeed could alternately be provided as a side effect of one or more of the tinderboxes still in operation, and could with some additional scripting automatically generate such packages. > Complexity is a pain-in-the-ass, you can't get rid of it, only shift it > around till it stops hurting. > > However, all that said, If we're going to shoot some kind of > documentation in the face for the pain its dependency-complexity > introduces, let it be "info". > > - Far fewer people enjoy or can actually get useful information out of > info pages > - Its build tooling frequently has dizzying problems in dependency > complexity and fragility, frequently made worse by portage getting > build ordering wrong after perl upgrades.[1] > > (Hopefully we've fixed the worst of that, but this is plutonium, a gift > that keeps giving cancer) > > 1: https://bugs.gentoo.org/buglist.cgi?quicksearch=texinfo > Since when is anyone proposing extirpating man pages on the whole? I am simply making the rather simple suggestion that pulling in more packages to support presently optional documentation as newly mandated documentation when such documentation is neither expected nor desired by the users of systems onto which it would be installed is not a net benefit to anyone. Even default on USE flags would be a better "fix" for the purported problem then making maintainers generate, package, and publish man pages themselves.
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 07/24/19 10:40, Kent Fredric wrote: > On Tue, 23 Jul 2019 23:56:52 -0400 > desultory wrote: > >> avoid optional documentation, >> while the proposal in question explicitly would > > I assume you meant 'optional dependencies' here right? :) > The user-side effects pf the proposal in question, were it to become policy, would be that anyone seeking to not install what is presently optional documentation would either be: (1) wasting build time and space (and, depending on implementation, dependencies) on their build system (potentially masking the files from being installed); (2) wasting the space in their installed image(s) (if they did not mask the files which would not currently be installed anyway); or (3) wasting their own time working around what the developers would be required by policy to implement by repackaging the software themselves to avoid the time and space drawbacks (though this would generally be expected to be a rather exceptional case, as it would be relatively extreme to avoid what would be a distfile and some file masking from the user side). Developer-side effects of the proposal in question would explicitly force developers to use bespoke workarounds to avoid adding optional dependencies to packages, for questionable gains. So, while I was commenting on user-side effects, the phrasing applies to developer-side effects given s/documentation/dependencies/. As I have noted elsewhere, there is a solution for which the majority of the tooling exists which could achieve the same ends as the proposal in question without causing developers in general significant additional overhead beyond the status quo, while as a side effect providing additional services to users. However, the proposal in question specifically avoids offloading the newly generated work to automated systems in favor of, evidently, optimizing for maximum consumption of resources with minimal standardization.
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 07/23/19 09:02, Jaco Kroon wrote: > Hi Michał, > > On 2019/07/23 14:39, Michał Górny wrote: >> On Wed, 2019-07-24 at 00:17 +1200, Kent Fredric wrote: >>> On Tue, 23 Jul 2019 13:38:28 +0200 >>> Gerion Entrup wrote: >>> What about a compromise?: Deliver a (prebuild) manpage as package maintainer by default, but keep a use flag "man-build" (or whatever) that builds the man page for everyone (also the maintainer herself) with use of the crazy extra deps. So a user can do (incomplete) version bumps and gets a manpage and the maintainer gets the prebuild manpage in a defined way. >>> You're missing the part where the maintainer is, by the policy, >>> required to, for every bump: >>> >>> 1. Ensure the generated documentation is extracted from the build >>> 2. Packaged into a tarball somewhere >>> 3. Uploaded to a server that can host that tarball >>> 4. Update the package to use that. >>> >>> Failure to do this will mean you're shipping out-dated documentation to >>> the user. >> I fail to see how this could happen, unless you'd be using terrible >> hacks. > And therein lies the issue. We would. >>> This series of back-flips is just not practical at present, and >>> introduces more steps where mistakes can break the ebuild. >> From this thread, it seems that most devs find it impractical to even >> test their ebuilds. > > No. They've been saying that the overhead of maintaining the above > mentioned terrible hacks is unacceptable. Imagine this: > > In order to build man pages I need to pull in 20 additional packages. > So when I roll new ebuild, I need those 20 ... not an issue for me, so > now I need to build the man pages, and I need to create a tarball with > those. A tarball which won't exist at the time when I initially build, > so it's not available to generate a Manifest. So first I have to avoid > those from SRC_URI completely. Then once I've deployed the pre-built > manpages, I need to re-add it. > > So every time there is an upstream version bump, this needs to be > rechecked and determined whether the manpages also needs to be bumped, > or I need to bump unconditionally. More overhead. > > This is outright annoying. Unless it can be automated properly. And I > believe it might be possible, but it'll involve yet more base complexity > by adding build-time dependencies to build man pages to a separate > depend (or at least flag them with a USE=buildman flag), somehow portage > would need to first sort out the building and deployment of the separate > SRC_URI for man pages before adding to the Manifest. You get where I'm > going I hope. > > Everybody agrees with your base premise: It's ideal to ship (optional) > documentation along with every single package, especially if it doesn't > have to pull in a boatload of dependencies. > As an apparently noncorporeal being, I am curious as to why the opinions of other apparently noncorporeal beings [1] are not valued. Further, I would like to remind you that shipping documentation by default does not necessarily imply forcing workarounds to avoid optional documentation, while the proposal in question explicitly would. [1] https://archives.gentoo.org/gentoo-dev/message/f9503369d19a2efd635eb90ac472a962 > Kind Regards, > Jaco > > >
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On 07/22/19 21:08, Aaron Bauman wrote: > On Sat, Jul 20, 2019 at 06:16:24PM -0400, Rich Freeman wrote: >> On Sat, Jul 20, 2019 at 4:22 PM Michał Górny wrote: >>> >>> >>> Yes, I get it. User experience is not important if it would mean >>> developers would actually do anything but the bare minimum to get >>> from one paycheck to another. The usual Gentoo attitude. >>> >> >> Not sure where I go to sign up for those paychecks. However, even >> employers have to accept that policies have a resource cost to them. >> >> Requiring people to do more than the bare minimum often just ensures >> that they won't even bother to do the bare minimum. I'm all for > > I do like that. I will send you the royalties for quoting you. > >> finding ways to standardize things so that everybody benefits at a >> very low cost. This doesn't seem that, and honestly requiring >> packages to bundle pre-built manpages seems a bit non-Gentooish to >> begin with. >> >> -- >> Rich >> > > Regarding pre-built manpages, I think you have missed Michal's (yea, I don't > fancy letters on my keyboard) point here. He is looking at a compromise of: > > 1. I want some documentation > 2. It doesn't ship from upstream (without crazy extra deps) > 3. Gentoo guy hooked me up and packaged it pre-built with it > 4. Thanks! > This seems rather more like an argument for reviving GRP with the flags to generate man pages enabled [1] and encouraging people to install from that without installing build-only dependencies if they need all of the documentation while maintaining a smaller installed footprint and dependency graphs than it does for requiring ebuild maintainers to jump through hoops and remove such flags because of yet another not quite thought through proposal. [1] No points for guessing where a ready supply of prebuilt man pages could be found if that were to be done. Nor for realizing that making manpage packages out of it could probably be robustly scripted in less time than has been invested in this discussion so far.
Re: [gentoo-dev] Gentoo on Discord
On 04/29/19 17:04, Mike Gilbert wrote: > On Mon, Apr 29, 2019 at 4:34 PM Dirkjan Ochtman wrote: >> >> In this article on chat services used for OSS: >> >> https://catfox.life/2019/04/28/keeping-libre-software-accessible-to-all/ >> >> I was surprised to see a mention of Gentoo as a project that uses "Discord >> as an official method of communication". When I searched, I indeed found >> https://discordapp.com/invite/gentoo. However, I'd never before heard we >> were using Discord (and didn't find any mentions of Discord on the -dev or >> -project mailing lists). >> >> Is this indeed an official venue? It's not listed on >> https://gentoo.org/support/ (which does mention IRC). > > Based on the #server-info channel, it looks like this server was > created by Cynede. Perhaps they have more information. > > Considering the reaction that I got when I asked him, I would advise against bothering with contacting cynede about it. Specifically, when I asked on irc the response was serial evasive answers and when I followed up with e-mail the response mentioned the PR project wiki page (without actually linking to it) and expressly requested that I never discuss it with him again, that request was followed up with the same request being made in a public irc channel, just because I was looking for a straight answer and consistently not getting one. Also, I was accused of being a sockpuppet for having asked, despite using my gentoo cloak on freenode at the time. As I was eventually able to discover, PR (or at least some members thereof) describes any site on which the PR project has an account (in the case of discord this type of account is known as a "server") to be an "official" communications channel. These "official" communications channels are not announced when created and do not have projects, even PR sub-projects to tend to them, nor are they listed among the support venues are they are evidently not for user support, as they are evidently intended simply for announcements and such they are merely listed on the PR project wiki page [PR]. [PR] https://wiki.gentoo.org/wiki/Project:Public_Relations
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/24/19 01:19, Matt Turner wrote:
> On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
>>
>> On 02/20/19 02:36, Michał Górny wrote:
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>
>>>>
>>>>> # Don't install libtool archives (even for modules)
>>>>> - prune_libtool_files --all
>>>>> + find "${D}" -name '*.la' -delete || die
>>>>
>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>
>>> I suppose you should have spoken up when people started adopting that
>>> 'find' line all over the place. Though I honestly doubt we're going to
>>> see many packages installing '*.la' non-files.
>>>
>> Just so we are all clear here: your argument is that more fully correct
>> approaches should not be considered in the present and future because
>> less fully correct approaches were implemented in the past? And,
>> further, that since nothing matching a specific pattern happens to come
>> to your mind at he moment, such things do not exist? Perhaps dialing
>> back the rhetoric from 11 and considering feedback as an opportunity to
>> improve existing code is called for in this case, among others.
>
> I think you might be reading more into this than was intended.
>
I am reading into it what was written into it.
> I read his email as lamenting that the horse has left the barn, so to
> speak.
Since we are going with animal husbandry analogies, his specific manner
of rejecting feedback was more akin to leaving the barn door open,
letting the horse go play in traffic and ignoring that there is no real
reason to believe that the horse will not be killed by a vehicle on the
basis of it has only been hit a few times and has not yet succumbed to
its injuries.
> There are already hundreds of uses of find -name '*.la' -delete
> without -type f in the tree, probably in large part because
> ltprune.eclass suggests the form without it.
>
Which, following the animal husbandry theme brings us to the elephant in
the room [1]:
"
# @MAINTAINER:
# Michał Górny
"
Given that another developer has noted two different issues with the
suggested boilerplate [2][3], why has he, as a member of QA and as
maintainer of the eclass in question, rejected or simply ignored their
concerns? He would not even need to override another maintainer to fix a
*comment* in that eclass. Is asking for rationale somehow that much of a
problem?
> Suggesting dialing down the rhetoric when it appears that you have
> overreacted is a bit humorous.
>
Given his behavior, it hardly seems so to me.
>
[1] https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/ltprune.eclass
[2]
https://archives.gentoo.org/gentoo-dev/message/d528ab54d230afc11430ea9660c7feaa
[3]
https://archives.gentoo.org/gentoo-dev/message/539b9ba7d4b21086bc2ba3b8d11dacdb
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/24/19 04:04, Michał Górny wrote:
> On Sat, 2019-02-23 at 22:19 -0800, Matt Turner wrote:
>> On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
>>>
>>> On 02/20/19 02:36, Michał Górny wrote:
>>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>>
>>>>>
>>>>>> # Don't install libtool archives (even for modules)
>>>>>> - prune_libtool_files --all
>>>>>> + find "${D}" -name '*.la' -delete || die
>>>>>
>>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>>
>>>> I suppose you should have spoken up when people started adopting that
>>>> 'find' line all over the place. Though I honestly doubt we're going to
>>>> see many packages installing '*.la' non-files.
>>>>
>>>
>>> Just so we are all clear here: your argument is that more fully correct
>>> approaches should not be considered in the present and future because
>>> less fully correct approaches were implemented in the past? And,
>>> further, that since nothing matching a specific pattern happens to come
>>> to your mind at he moment, such things do not exist? Perhaps dialing
>>> back the rhetoric from 11 and considering feedback as an opportunity to
>>> improve existing code is called for in this case, among others.
>>
>> I think you might be reading more into this than was intended.
>>
>> I read his email as lamenting that the horse has left the barn, so to
>> speak. There are already hundreds of uses of find -name '*.la' -delete
>> without -type f in the tree, probably in large part because
>> ltprune.eclass suggests the form without it.
>>
>> Suggesting dialing down the rhetoric when it appears that you have
>> overreacted is a bit humorous.
>>
>
> He simply decided to stalk me and issue ad hominem attacks whenever he
> can. It's how professionals in Gentoo react to critique.
>
I am hardly "stalking" you. I am addressing bad ideas and poor
maintainer behavior, that it happens to be yours is immaterial to me.
Besides, you effectively demanded that I participate more broadly[1], so
do kindly pick one sort of libel and stick to it. As contradicting
yourself not only weakens your argument (were it to have a basis to
begin with), it makes malicious intent more obvious.
As for ad hominem attacks, do kindly present examples, I would be most
interested in any which you can demonstrate are unjustified. When I ask
if/how/why your behavior is acceptable for someone in your roles, I am
seriously asking that question. I want to know the rationale, especially
under what are, at least nominally, the rules governing the interactions
and behaviors which I am inquiring about. Though I will forego linking
to that, as that evidently annoys you.
[1]
https://archives.gentoo.org/gentoo-project/message/b498bcfaf34ffc355eaba3afafd1ee96
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 02/23/19 16:16, Michał Górny wrote: > On Sat, 2019-02-23 at 15:39 -0500, desultory wrote: >> On 02/23/19 02:17, Michał Górny wrote: >>> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: >>>> On 19-02-19 22:05:02, Brian Dolbec wrote: >>>>> On Tue, 19 Feb 2019 23:03:51 -0600 >>>>> Matthew Thode wrote: >>>>> >>>>>> On 19-02-20 00:00:04, Michael Orlitzky wrote: >>>>>>> On 2/19/19 11:21 PM, Matthew Thode wrote: >>>>>>>>> >>>>>>>>> What problem would this solve? (Is adding gentoo-keys to @system >>>>>>>>> the least bad way to solve it?) >>>>>>>>> >>>>>>>> >>>>>>>> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify >>>>>>>> portage tarballs. This is useful for the initial sync (as called >>>>>>>> out in our manual). Otherwise using emerge-webrsync could be >>>>>>>> mitm'd or otherwise messed with. >>>>>>> >>>>>>> Ok, then I agree with the goal if not the solution. This is a >>>>>>> portage-specific thing, namely >>>>>>> >>>>>>> FEATURES=webrsync-gpg >>>>>>> >>>>>>> that should be enabled by default on a stage3. (Making new users go >>>>>>> out of their way to add basic security is daft.) Portage already has >>>>>>> USE=rsync-verify, and I think we could either >>>>>>> >>>>>>> a) expand the meaning of that flag to include enabling >>>>>>> webrsync-gpg by default, and to pull in gentoo-keys; or >>>>>>> >>>>>>> b) add another (default-on) flag like USE=webrsync-verify to do it >>>>>>> >>>>>>> That flag would be enabled by default, so gentoo-keys would be >>>>>>> pulled in as part of @system without actually being *in* the >>>>>>> @system. Something along those lines would achieve the same goal in >>>>>>> a cleaner way. >>>>>>> >>>>>>> >>>>>> >>>>>> This worksforme (optional, default enabled dep of portage with a >>>>>> default feature flag change). >>>>>> >>>>>>>> As far how we treat deps of @system packages, since this does not >>>>>>>> have any deps that should help check that box for anyone >>>>>>>> worried. >>>>>>> >>>>>>> I meant the other way around. Once gentoo-keys is in @system, >>>>>>> packages will (inconsistently) omit gentoo-keys from (R)DEPEND. >>>>>>> There's no real policy or consensus on the matter, and it makes it >>>>>>> a real PITA if we ever want to remove things from @system, because >>>>>>> lots of packages will break in unpredictable ways. >>>>>>> >>>>>> >>>>>> Ah, ya, that makes sense. >>>>>> >>>>> >>>>> One of the things that releng has bantered about the last few years is >>>>> making a stage4 with these extra non @system pkgs. The stage4 would >>>>> allow all the extra pkgs needed for new installs without adding to >>>>> @system. The system set could possibly be trimmed a little more then >>>>> too. Then knowledgeable users could work with minimal stage3's when it >>>>> suits their purpose while new users doing installs get the advantage of >>>>> the additional pre-installed pkgs. >>>>> >>>> >>>> Ok, after setting that up portage wants to update pgp keys, which fail >>>> because keyservers suck. It doesn't look like we can change the >>>> keyservers or disable the update entirely but we can set the retries to >>>> 0 (which better disable it...). Robbat2 had a patch to allow disabling >>>> the update but it doesn't look like it was applied. >>>> >>> >>> Disabling that means entirely killing the verification as it'd happily >>> use a revoked key. >>> >>> Keyservers were supposed not to suck anymore. Are you sure it's not >>> misconfigured network? Maybe it's got broken-but-pretended IPv6? >>> >> >&
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/23/19 03:42, Andrew Savchenko wrote:
> On Fri, 22 Feb 2019 23:30:15 -0500 desultory wrote:
>> On 02/20/19 02:36, Michał Górny wrote:
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>
>>>>
>>>>> # Don't install libtool archives (even for modules)
>>>>> - prune_libtool_files --all
>>>>> + find "${D}" -name '*.la' -delete || die
>>>>
>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>
>>> I suppose you should have spoken up when people started adopting that
>>> 'find' line all over the place. Though I honestly doubt we're going to
>>> see many packages installing '*.la' non-files.
>>>
>> Just so we are all clear here: your argument is that more fully correct
>> approaches should not be considered in the present and future because
>> less fully correct approaches were implemented in the past? And,
>> further, that since nothing matching a specific pattern happens to come
>> to your mind at he moment, such things do not exist? Perhaps dialing
>> back the rhetoric from 11 and considering feedback as an opportunity to
>> improve existing code is called for in this case, among others.
>
> If we are going to improve code, we should also use find -O3.
>
Please forgive my presumption, but I am going to infer that your comment
was neither meant to display gross ignorance of find (1) nor as a
strawman, but was instead merely a joke; and on that basis ask you a
question.
Why, in your opinion, should it be acceptable for a member of QA to
dismiss commentary on a piece of code on grounds that he knows to be
spurious? Especially code that has been noted, in this very thread, to
encounter cases where it does the wrong thing. Especially when the
proposed change actually removes a class of potential misbehavior of the
code in question.
The proposed change hardly appears to be difficult to implement,
difficult to maintain, expansive in scale, or obscure in nature; so none
of those concerns would appear to apply. Though it does miss at least
one obvious class of potential misbehavior, but that was not the basis
on which it was dismissed.
I eagerly await your insight.
>
> Best regards,
> Andrew Savchenko
>
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
On 02/23/19 02:17, Michał Górny wrote: > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: >> On 19-02-19 22:05:02, Brian Dolbec wrote: >>> On Tue, 19 Feb 2019 23:03:51 -0600 >>> Matthew Thode wrote: >>> On 19-02-20 00:00:04, Michael Orlitzky wrote: > On 2/19/19 11:21 PM, Matthew Thode wrote: >>> >>> What problem would this solve? (Is adding gentoo-keys to @system >>> the least bad way to solve it?) >>> >> >> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify >> portage tarballs. This is useful for the initial sync (as called >> out in our manual). Otherwise using emerge-webrsync could be >> mitm'd or otherwise messed with. > > Ok, then I agree with the goal if not the solution. This is a > portage-specific thing, namely > > FEATURES=webrsync-gpg > > that should be enabled by default on a stage3. (Making new users go > out of their way to add basic security is daft.) Portage already has > USE=rsync-verify, and I think we could either > > a) expand the meaning of that flag to include enabling > webrsync-gpg by default, and to pull in gentoo-keys; or > > b) add another (default-on) flag like USE=webrsync-verify to do it > > That flag would be enabled by default, so gentoo-keys would be > pulled in as part of @system without actually being *in* the > @system. Something along those lines would achieve the same goal in > a cleaner way. > > This worksforme (optional, default enabled dep of portage with a default feature flag change). >> As far how we treat deps of @system packages, since this does not >> have any deps that should help check that box for anyone >> worried. > > I meant the other way around. Once gentoo-keys is in @system, > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > There's no real policy or consensus on the matter, and it makes it > a real PITA if we ever want to remove things from @system, because > lots of packages will break in unpredictable ways. > Ah, ya, that makes sense. >>> >>> One of the things that releng has bantered about the last few years is >>> making a stage4 with these extra non @system pkgs. The stage4 would >>> allow all the extra pkgs needed for new installs without adding to >>> @system. The system set could possibly be trimmed a little more then >>> too. Then knowledgeable users could work with minimal stage3's when it >>> suits their purpose while new users doing installs get the advantage of >>> the additional pre-installed pkgs. >>> >> >> Ok, after setting that up portage wants to update pgp keys, which fail >> because keyservers suck. It doesn't look like we can change the >> keyservers or disable the update entirely but we can set the retries to >> 0 (which better disable it...). Robbat2 had a patch to allow disabling >> the update but it doesn't look like it was applied. >> > > Disabling that means entirely killing the verification as it'd happily > use a revoked key. > > Keyservers were supposed not to suck anymore. Are you sure it's not > misconfigured network? Maybe it's got broken-but-pretended IPv6? > Given the ongoing volume of issues with this same area that have been reported on the forums (and elsewhere), including by people whom I know to be competent network administrators, it seems distinctly unlikely that all of the issues come down to networking configuration errors. Especially as the posited networking issues appear to affect nothing else.
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On 02/20/19 02:36, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>
>>> # Don't install libtool archives (even for modules)
>>> - prune_libtool_files --all
>>> + find "${D}" -name '*.la' -delete || die
>>
>> Maybe restrict removal to regular files, i.e. add "-type f"?
>
> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place. Though I honestly doubt we're going to
> see many packages installing '*.la' non-files.
>
Just so we are all clear here: your argument is that more fully correct
approaches should not be considered in the present and future because
less fully correct approaches were implemented in the past? And,
further, that since nothing matching a specific pattern happens to come
to your mind at he moment, such things do not exist? Perhaps dialing
back the rhetoric from 11 and considering feedback as an opportunity to
improve existing code is called for in this case, among others.
Re: [gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml
On 09/27/18 10:21, Michał Górny wrote: > On Fri, 2018-09-28 at 01:50 +1200, Kent Fredric wrote: >> On Mon, 24 Sep 2018 07:59:46 +0200 >> Michał Górny wrote: >> >>> I'm against dumb timeouts. Good timeout = die if nothing happens for T. >>> Bad timeout = die if process doesn't finish for T (yet it may still be >>> doing something). >> >> Could you perhaps adjust it so that when the timeout limit is exceeded, >> the sync is aborted, and the sync status of that repository is flagged >> as "bad", and notifies you somehow to fix it manually at your leisure, >> but otherwise ceases to impede the progress of all the other >> repositories? >> >> And if you're worried that a sync interruption midway could cause a >> dirty state, maybe you could do an rsync trick where mercurial repos >> are rsynced into a sandbox location, and then only rsynced back into >> place on success? >> >> This process lets you go "sure, it may be doing something, but it took >> too long anyway, so we'll let somebody with brains work it out and >> pretend it was broken in the interim" > > No. > Elucidate.
