Re: [gentoo-dev] Add bc back to the stage3
Jorge Manuel B. S. Vicetto wrote: > I've stopped following this mailing list regularly quite sometime ago. > To see this thread is still going on and no one bothered to cc releng, > to me shows a lack of respect I expected you to participate on the developer list to some degree, since you are developers. Isn't that even mentioned in a quiz somewhere? //Peter
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014, Tom Wijsman wrote: On Sat, 27 Sep 2014 13:22:45 +0100 Ciaran McCreesh wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. Vim is not fully POSIX compliant; you may find it claim "mostly" in its documentation, but that's where it stays at and thus doesn't suffice... While we're at it, we must make everyone use a POSIX IDE with a ribbon! Jokes aside, this sub discussion is pointless; if we want results, a moderated mailing list as suggested in a reply won't cut it! It seems like everyone needs to "chill" a bit. Ciaran wasn't trolling, he was making a point. I'm sure everyone around here understood his point. There were no attacks and no "foul language", so can we move forward? What is really needed here is a vote by the Council on whether to add bc back to the stage3. If the people do insist, another vote regarding adding or changing an editor to stage3 could be done as well. No, there isn't a need for a Council vote here. This is something up to Releng (in respect to what is in the stages) and to everyone in respect to what is part of the system set. Further, to me, this is a case where if anyone tries to side-step Releng and go over it with a Council decision, than the council members should be ready to start doing Releng work. I've stopped following this mailing list regularly quite sometime ago. To see this thread is still going on and no one bothered to cc releng, to me shows a lack of respect for the people actually doing releases around here, as well as a real lack of interest in getting this done as you can discuss this all you want, but in the end, it's releng that works on this. Regards, Jorge Manuel B. S. Vicetto Gentoo Developer (Releng Lead)
[gentoo-dev] Re: Re: Looking for alternative to RESTRICT=userpriv
On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote: > On 07/09/2014 07:17 AM, Michał Górny wrote: > >>> c) 'esudo' helper [3]. This is a more generic form of (2), with > >>> support for other potential privilege changes. > >> .. > > I don't think we'd use the reference 'sudo' impl. Rather some > > in-portage helper, possibly setuid. Or portage's IPC but that would > > imply running the command in an isolated environment (possibly > > beneficial). > > The environment doesn't necessarily have to be isolated, since we could > extend the existing environment saving/loading support to be used for by > esudo. The steps to implement the shared environment could be as follows: > > 1) When esudo is called, it saves the current (unprivileged) bash > environment to a file. > > 2) esudo uses IPC to request that a process with elevated privileges be > launched to run a specific command using the saved environment, and that > the environment of the elevated process be saved to a file after the > command completes. I don't think it's going to be quite that easy to get the output env, certainly not from some random command; tbh I don't even see the need for it, unless I'm missing something. From the "elevated process" after it waits on the child, but not from the child unless you control the code. > 3) Before esudo returns, it loads the environment that was saved by the > elevated process before it exited. What's the use-case for this part? I could see it with a function, but then you just run that as part of the ebuild. For running a specific command to access a device with privilege, or to add a user etc, I don't really see the point. (so why bother with the implementation complexity.) Other than that, I agree esudo is the best approach, and gives us much better granularity over privilege escalation, as discussed in the bug. Part of me thinks though, that it'd be much cleaner to give the portage user access to sudo. Isn't that effectively the purpose of the "suid helper"? In which case we get all the options for env etc, of sudo, and the admin gets to configure it along with the normal wheel setup. Just a thought. Regards, igli -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Add bc back to the stage3
On Sat, Sep 27, 2014, Luca Barbato wrote: > On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote: > > On Wed, 17 Sep 2014, Luca Barbato wrote: > > > >> The bc utility is part of the posix tools and it might be used to build > >> linux among the other stuff. > > > > Luca, > > > > bc is not in the system set and is a dependency of the kernel or any > > other package that needs it, so why do we need to include a package that > > takes ~20 seconds to build? > > Because I'd expect a stage3 to be posix compliant and it is a pain to > remember that Gentoo doesn't have it by default (since the errors can be > quite vague). > I agree; ed should be supplied too for the same reason (and not be considered as a provider for the virtual.) It's a pita not being able to rely on a POSIX.2 base. Similarly with vi/ex too (again, not providing the virtual); though vim should likely be another package, unless it's much easier just to bundle it. AFAIR you get into all the gvim/X questions then, but I can't say as I use it, so defer to whomever. ex is useful for scripters, though we use ed more, since it avoids the vi question and we've had reports of ex not being as reliable as ed, on other platforms. busybox ed should never be built afaic. GNU ed has tight linkage for rootfs usage (like sed and awk, which should be in /bin), and actually works: $ ldd $(type -p ed) linux-vdso.so.1 libc.so.6 => /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 Regards, steveL -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014 19:39:44 -0400 "Anthony G. Basile" wrote: > And now for something completely different ... drum roll ... Really! > We have to have a council vote on whether bc goes into stage3? If > this does go to the council, then I want a pre-vote vote: should we > bounce the decision back to the releng team? We should not micro > manage to this level. The Council gets involved when there is disagreement, which makes this more serious than micro management; but sure, if they want to revisit the case then that could work out as well. The releng team's input on this case is important, even if it ends up going to Council.
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sat, 27 Sep 2014 18:45:12 -0400 Rich Freeman wrote: > So, there was some discussion on -dev, apparently some discussion I > wasn't a part of, and some that I was (such is the nature of IRC). Knowledge codification is nice; otherwise, this is just-another-thread. > I think it would make sense to take a step back and ask what we'd do > if we were starting with a blank slate. Aliases, herds, and projects > are all ways of grouping people, but they are used in different ways, > sometimes. Looking at a blank slate hides the origin of these ways. Aliases set up mails on the infrastructure. Herds assign multiple relevant maintainers to multiple packages. Projects are a need for serious organization. This is what we have ended up with starting from that blank slate. > My real problem with herds isn't the idea of having more than one way > to group people. My real issue is that we have several ways of > grouping people and no consistent way of doing so. You have to look > in different places to find out who is on an alias/herd/project. We > have cases where more than one of these are loosely associated, but > membership is inconsistent. Aliases are there to support herds or projects, it shouldn't be seen as a separate way to group people. The other groups are straight froward; herds for groups that maintains packages, projects for groups that take on a serious project. Projects that take on packages have created herds (eg. proxy-maintainers, ...); so, this is or can be consistent. > We have inactive examples of all three. Yes, they capture inactivity; iotw, what's in a herd/project name? :) > So, let's step back and think about why developers would want to be > part of a group, forget about what we call these groups, and then > figure out what kind of model makes the most sense and how to get > there. In the final design we might want to not split groupings up > all over the place (wiki vs herds.xml vs alias files that nobody but > devs can read). > > So, one level of association might be registering an interest - such > as what is sometimes done with a mail alias. A developer, or even a > non-developer, might want to be informed about what is going on with a > package or group of packages, but they are not making any kind of > commitment to actually taking care of them. > > The opposite would be a project as defined in GLEP 39. This is a > formal association of developers that elects a lead, and acts as a > unit. The project could establish policies and it is generally > expected that they be followed (we can escalate to the Council if > there is a problem). This is especially valuable for core > dependencies like toolchain, frameworks, etc where good planning makes > everybody's lives easier. > > Then you have groups of people who sort-of maintain peripheral > packages, which is what I think is what many herds are (but their use > is totally inconsistent, so this isn't true everywhere). If read and compared correctly, the origin paragraph is a TL;DR to this. > My issue with this sort of thing is that it is really hard to tell if > a package is actually maintained. Devs basically drop-in to scratch > an itch and then abandon things. Emails to aliases get ignored, > since nobody in particular is in charge. > > That is my main issue with herds - they're dumping grounds for bugs > that nobody seems to care about, at least in some cases. +1, as some of us revealed; but note that projects can also hide abandoned efforts, eg. the Council recently cleaning old dead projects. > With a project you can at least ask "have you selected a lead in the > last year" and get some kind of pulse on activity. There are projects which haven't selected a new lead for years ... > Herds are nice from the standpoint that they cost nothing to > maintain, but that also means that there is no way to gauge > commitment. Having an election is a big like some proposals to > charge $1 to register a copyright renewal - it isn't about the cost > so much as just making somebody actually do something to prevent > de-listing. ... thus it only works when some entity external to the project forces new lead elections; as otherwise, projects have no such $1 ping-pong. > I guess my question is when is something like a herd the best solution > to a problem, and what is that problem? Unnecessary stuff: Organization, knowledge codification, time, work, ... > I don't want to change for the sake of change. If we stay the same > I'd like it to be because what we're doing actually makes sense. It made sense to me from day #1 of contributing to Gentoo; it surprises me that this all of the sudden is assumed to be a problem, it makes me rather skeptic about whether a structure change is needed. > If we do keep something like herds, I'd still consider some way to > consolidate herd/project membership lists so that tools can scan a > single location. Whether a group is a herd/project/alias could be an > attribute. This i
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Sun, 28 Sep 2014 00:21:43 +0200 Michał Górny wrote: > I don't know if you know it but setting up the project wiki page takes > less time than reaching into depths of CVS and editing herds.xml. Editing and committing a change to herds.xml takes me less characters than this quoted paragraph, done in under a minute; in comparison, a project wiki page involves a browser, waiting time and more characters. > Otherwise, we'll never going to get out of the dumb distinction what > project and herd is and isn't, and when one or the other, or both > should be used. The documentation and GLEP(s) are pretty clear about that; as for how to use it, that are semantics that are up for the projects and herds. This has worked fine for ages, point me to old threads discussing this if you claim that to not be the case. Recent assumptions make it look like it is a problem, but a history of experience tell us otherwise...
Re: [gentoo-dev] Add bc back to the stage3
On 09/27/2014 07:39 PM, Anthony G. Basile wrote: > On 09/27/14 18:46, Rich Freeman wrote: >> On Sat, Sep 27, 2014 at 5:52 PM, Tom Wijsman wrote: >>> What is really needed here is a vote by the Council on whether to add bc >>> back to the stage3. If the people do insist, another vote regarding >>> adding or changing an editor to stage3 could be done as well. >>> >> The call for agenda goes out on Tuesday, so if somebody wants a vote >> please put it up. Don't let mgorny be the only one with agenda items. >> :) >> >> -- >> Rich >> > He isn't ... remember GLEP 64 :) > > And now for something completely different ... drum roll ... Really! We > have to have a council vote on whether bc goes into stage3? If this > does go to the council, then I want a pre-vote vote: should we bounce > the decision back to the releng team? We should not micro manage to > this level. > May I suggest an alternative? We could implement sys-virtual/posix and make it depend on all packages that are not necessary for @system, but are necessary for proper POSIX compliance. Then we can tell users who need/want an environment containing all tools specified by POSIX, such as those not using sys-kernel/*-sources, to `emerge virtual/posix`. That said, the larger matter of standards conformance that needs to be considered. Illumos' Garrett D'amore has been working on standards conformance tests for libc: https://bitbucket.org/gdamore/illumos-gate/src/8815a50c9cc3f6f213931e12f72c252504363a82/usr/src/test/libc-tests/?at=core Garrett told me yesterday that the changes necessary to run them on Linux should be very small and are likely restricted to a few dozen lines in 1 file. I want to try running them to catch POSIX conformance issues in our base system. That will likely come later this year, as I recently became aware of a SUS conformance issue in ZFS' implementation of mmap() where PROT_WRITE + MAP_PRIVATE on a readonly file fails. Fixing that will take priority over reviewing the standards conformance of libc (others can review libc before i do if they wish). I imagine that the tests will catch issues in our present conformance when they are run. Once we have the results, we will need to decide how proactive we intend to be about fixing them. We will definitely want to work with upstream libcs to get issues that tests identified fixed. However, there would be the question of whether we wish to fix them immediately or wait for the patches fixing them to be upstreamed. If the matter of adding bc to the base system for POSIX conformance goes to the Council, it might be worth thinking about how far we wish to go for standards conformance when further issues are identified. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add bc back to the stage3
On 27/09/14 15:19, Luca Barbato wrote: On 27/09/14 14:22, Ciaran McCreesh wrote: On Sat, 27 Sep 2014 12:47:14 +0200 Luca Barbato wrote: Because I'd expect a stage3 to be posix compliant I agree. It's time to replace nano with Vim. Surely certain stuff might enjoy having ex available as well. Probably busybox could be enough for both use-cases. What about documenting this detail somewhere? lu
