Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Thu, Oct 16, 2014 at 12:13:45AM +, Jorge Manuel B. S. Vicetto wrote: > For stage1 and stage2 the *order* we build packages is relevant. Is this really true? The stage1 is being built with ROOT, so it's only using the seed stage3 packages. It's hard to have cyclic dependencies when you're using packages from one root (the seed stage3) but installing into another (/tmp/stage1root). Looking through a stage1 log I see: emerge --quiet --oneshot --nodeps --update sys-apps/portage … emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc … emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps sys-apps/baselayout … emerge --quiet --usepkg --buildpkg --newuse --oneshot sys-devel/gnuconfig sys-devel/bison … The first two are just covering us against serious missmatches between the package tree and the seed stage3 (and are installed with ROOT=/). I expect we could handle shoving baselayout into the final emerge along with the other packages.build stuff. The logs for stage2 aren't as clear, but looking through the script I only see: * A Portage-updating emerge * The main GCC, binutils, … emerge * A possible 'emerge --prune sys-devel/gcc' I'm not sure this is needed at all. I'll try and find time to build a stage3 directly from a stage1, and we'll see if it blows up ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, 10 Oct 2014, Rich Freeman wrote: On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wrote: On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. All of the above suggestions would require changes to catalyst. In any case, given the way we build a stage1 and bootstrap stage2, that isn't possible. For stage1 and stage2 the *order* we build packages is relevant. We rely on portage following that list in sequence. Furthermore, because of the implicit dependencies and issues with circular dependencies, it would likely be impossible for portage to resolve the list of packages to build for stage1 and stage2 from a virtual. The build system would just iteratively start at the bottom and output a tarball or whatever as each level is completed, then use that as the basis for bootstrapping the next. That's how catalyst already works. To address one point in your last sentence in the above quote: "The root stage would not depend on another stage, and therefore would be built from the host system." You almost always don't want to build with the state of a live system, but of a clean seed - that's why releng tells catalyst to use a stage3 as the seed for the stage1. Such a design would also eliminate the need to have the same list of packages define the contents of @system and a stage3. It could also support any number of stages, with any names we wish. No, not really. You're "over-thinking" this. To be able to "split" the system set and the stages releng provides, all we need is to fix the bug that was already mentioned before and have releng provide stages built from a stage3 (while removing some packages from the system set) and a list of packages that we want to provide (the ones dropped from system and a select "few" others). I would also still have stage builds use a profile of some kind - that could be useful from a standpoint of setting USE flags and so on. However, if it made sense to build earlier stages with different flags they could still be specified as USE dependencies (maybe due to circular deps you have to build a package with different set of USE flags before you can build the desired USE flags in a later stage). We build stages using a profile. One of the variables set on stage specs is "profile" to list the profile to be used in the stage. -- Rich Regards, Jorge Manuel B. S. Vicetto Gentoo Developer PS - As I've warned before, I'm not following closely the dev ml. So you got this reply now, because I just happened to look at the emails in this ml. If you want me to comment further, your best option is to poke me about it.
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:45:37PM -0400, Rich Freeman wrote: > Obviously this entails work on somebody's part, but would it still > make sense to make the stage build process more generic along the > lines Robin suggested? That is, instead of having 3 specific places > we use to generate a stage1/2/3, we instead just define a stage as a > virtual of some kind that optionally depends on another stage (not > necessarily using the standard DEPEND mechanism) and then pulls in a > list of packages. The root stage would not depend on another stage, > and therefore would be built from the host system. Why bother with multiple layers and per-profile package lists if a straight emerge is all you need? My ideal long-term situation would be to explicitly list all a package's dependencies (no implicit @system dependencies). Then have the stage1 just emerge a self-hosting virtual/toolchain (which can have per-arch dependencies if it needs them) from an arbitrary seed, and stage2 rebuild -e using itself. Everything after that could be user-generated @world stuff, and you might want virtual/release with nano and whatever else you want to put up under releases/$ARCH/autobuilds/gentoo-$ARCH-$DATE.tar.bz. That's less magical, and Catalyst could be a bit simpler, but I don't have the energy to move things there ;). It's also pretty much what we have now, except @system is floating around between virtual/toolchain (our current stage1 packages) and virtual/release (our current stage3 packages). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wrote: > On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: >> In a similar vein, would releng be open to moving stage1/2/3 package >> sets to virtual packages or package sets? Presently they are inside >> catalyst, and I think this would clean things up a lot. > > They're already in the Portage tree (the profile's packages.build for > stage1, scripts/bootstrap.sh for stage2, and the profile's packages > for stage3) [1]. Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. The build system would just iteratively start at the bottom and output a tarball or whatever as each level is completed, then use that as the basis for bootstrapping the next. Such a design would also eliminate the need to have the same list of packages define the contents of @system and a stage3. It could also support any number of stages, with any names we wish. My intent here isn't to get three cheers for making the releng team do more work. I'm actually more interested in feedback as to whether there are any obvious flaws in an approach like this that I'm missing, or whether something entirely different would be better. I would also still have stage builds use a profile of some kind - that could be useful from a standpoint of setting USE flags and so on. However, if it made sense to build earlier stages with different flags they could still be specified as USE dependencies (maybe due to circular deps you have to build a package with different set of USE flags before you can build the desired USE flags in a later stage). -- Rich
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: > In a similar vein, would releng be open to moving stage1/2/3 package > sets to virtual packages or package sets? Presently they are inside > catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Cheers, Trevor [1]: http://git.tremily.us/?p=catalyst.git;a=blob;f=doc/HOWTO.txt;h=cec22c35484d480fa127beb7be6bbdd9e942dc39;hb=HEAD#l139 Linking to my public repo, because the gitweb service on git.overlays.gentoo.org is still broken. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote: > 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`. I like this idea, for a virtual/posix; would let us trim a lot of other things from some environments. In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Add bc back to the stage3
Hey Jorge, Jorge Manuel B. S. Vicetto wrote: > I know that our policies state that technical issues should be raised in > the dev ml, although they also support doing the discussion in specialized > mls, but they also mention that one should make an effort to contact those > involved in the matter. I completely agree that that is certainly the least someone can do. Thanks //Peter
Re: [gentoo-dev] Add bc back to the stage3
On Tue, 30 Sep 2014 18:58:18 +0100 Ciaran McCreesh wrote: > On Mon, 29 Sep 2014 23:37:20 +0200 > Tom Wijsman wrote: > > On Mon, 29 Sep 2014 04:05:19 + (UTC) > > "Jorge Manuel B. S. Vicetto" wrote: > > > 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. > > > > > > 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? > > > > Constructiveness does not rely on just making points, as replacing > > nano with Vim is out of the context of adding bc back to stage3. > > Editors are a world apart from a build tool, even more so from being > > POSIX. In order to move forward beyond this point, that needs to be > > recognized. Ah, quotes are getting cut out, lovely; it focuses on what is crucial.
Re: [gentoo-dev] Add bc back to the stage3
On Wed, Oct 1, 2014 at 7:59 AM, Jorge Manuel B. S. Vicetto wrote: > I know that our policies state that technical issues should be raised in the > dev ml, although they also support doing the discussion in specialized mls, > but they also mention that one should make an effort to contact those > involved in the matter. > ++ I think people just assume everybody reads these threads. That isn't always the case, and we can all stand a reminder once in a while... -- Rich
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014, Rich Freeman wrote: On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile wrote: Although, I must say, Jorge's is being little premature here, and I doubt the Council will act rashly. So, while I was trying to be balanced in my reply, I'll admit it may have still been a bit too emotionally motivated. I think this was really the bit that I was reacting to. In general I do agree that it is best to let individual teams make the call before escalating to council. I just don't like attitudes along the lines of "I'll do what I think is best, and if you don't like it you can do it instead." It is true that we're all volunteers, and we all need to be mindful of that. However, if all Gentoo is to somebody is a place to host their sole-committer git repo, you could probably do better. In this case I reacted more "emotionally" that I should have. Using your expression above, please consider it as "releng is doing what it thinks is best." As the team lead, I was also expressing that to see something as "ordinary" as deciding if bc should be in stage3 sent to the council to "decide", those pushing for that (and that critic wasn't directed to the council members but those pushing this to council), shouldn't be surprised if releng members get upset and decide to spend their time elsewhere. I don't really think that was how Jorge felt, and I think we're all just venting, and my response probably wasn't more helpful than what I replied to, so apologies to all for the line noise. Yes, I was venting. I got a bit upset to see something as simple and ordinary still being discussed (I believe the last time I read about it had been 2 weeks before). To me, this isn't the first time that someone decides to discuss in the dev ml about releng work, without even bothering to let releng know about it. I know that our policies state that technical issues should be raised in the dev ml, although they also support doing the discussion in specialized mls, but they also mention that one should make an effort to contact those involved in the matter. For what its worth, this still isn't on the agenda (I'll probably send out the call later today). I also think that if anybody is feeling really frustrated over the content of stage3/@system and so on, they're probably best off directing that frustration towards getting something like mix-ins supported. :) Gentoo is about choice, but we can only offer the choices that our tools support. -- Rich Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014 23:37:20 +0200 Tom Wijsman wrote: > On Mon, 29 Sep 2014 04:05:19 + (UTC) > "Jorge Manuel B. S. Vicetto" wrote: > > 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. > > > > 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? > > Constructiveness does not rely on just making points, as replacing > nano with Vim is out of the context of adding bc back to stage3. > Editors are a world apart from a build tool, even more so from being > POSIX. In order to move forward beyond this point, that needs to be > recognized. But POSIX does describe vi. That was the point... (And until fairly recently, texlive used to require 'ex' if you wanted to build it fully from unpatched sources.) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014 06:08:11 +0200 Peter Stuge wrote: > 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? Only a small few MLs are mandatory; as for most others, a developer is free to sub/unsub to/from a ML as they see fit. There was a mail[1] send out by the Gentoo Council regarding awareness of gentoo-dev ML threads. [1]: http://article.gmane.org/gmane.linux.gentoo.project/3549 (see 2-3)
Re: [gentoo-dev] Add bc back to the stage3
On Mon, 29 Sep 2014 04:05:19 + (UTC) "Jorge Manuel B. S. Vicetto" wrote: > 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? Constructiveness does not rely on just making points, as replacing nano with Vim is out of the context of adding bc back to stage3. Editors are a world apart from a build tool, even more so from being POSIX. In order to move forward beyond this point, that needs to be recognized. Does that make him attacking / foulish / trollish / unchilling? No; actually, it is helpful / smart / fluffy / chilling towards consensus as both the opposite and sarcastic interpretations help form that. > > 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. Not in the way of having the Council actually vote, but by waking up everyone from these endless side points sub discussions by escalation. > 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. If people desire a change, it'll be discussed for an eternity; until ...
Re: [gentoo-dev] Add bc back to the stage3
On 11:24 Sat 27 Sep , Anthony G. Basile wrote: > On 09/27/14 11:19, Mike Gilbert wrote: > > On Sat, Sep 27, 2014 at 8:22 AM, 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. > >> > > To restate this: There are numerous other utilities specified in POSIX > > which we do not have in @system (or the stage3 tarball). > > > Agreed. The argument "its posix and should be in there" doesn't fit the > criterion for a stage3 tarball. A stage3 should be "a minimal set from > which any gentoo system can be built" (modulo arch, abi, libc, ..., of > course.) Emerging any linux kernel package will pull in bc (see > REDEPEND in kernel-2.eclass) and therefore bc is not needed to complete > that minimal set. > (picking up the most relevant reply) Here[1] is the original discussion regarding the removal of bc and ed from the system set. I do prefer bc in system set too because I'm lazy to emerge the damn thing but their reasons were valid at that time(2005), and they 're still valid right now(2014). [1] http://thread.gmane.org/gmane.linux.gentoo.devel/27216 -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp2512vesqi0.pgp Description: PGP signature
Re: [gentoo-dev] Add bc back to the stage3
On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile wrote: > Although, I must say, Jorge's is being little premature here, and I > doubt the Council will act rashly. So, while I was trying to be balanced in my reply, I'll admit it may have still been a bit too emotionally motivated. I think this was really the bit that I was reacting to. In general I do agree that it is best to let individual teams make the call before escalating to council. I just don't like attitudes along the lines of "I'll do what I think is best, and if you don't like it you can do it instead." It is true that we're all volunteers, and we all need to be mindful of that. However, if all Gentoo is to somebody is a place to host their sole-committer git repo, you could probably do better. I don't really think that was how Jorge felt, and I think we're all just venting, and my response probably wasn't more helpful than what I replied to, so apologies to all for the line noise. For what its worth, this still isn't on the agenda (I'll probably send out the call later today). I also think that if anybody is feeling really frustrated over the content of stage3/@system and so on, they're probably best off directing that frustration towards getting something like mix-ins supported. :) Gentoo is about choice, but we can only offer the choices that our tools support. -- Rich
Re: [gentoo-dev] Add bc back to the stage3
On 09/29/14 07:14, Rich Freeman wrote: On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto wrote: 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. I don't think many really care about deferring to releng on what is in the stages. My concern is what is in @system, since that has a big impact on everybody. The original point and reasoning was about getting bc back into stage3. The @system discussion came up secondarily because of the relationship between the two. But note that, if the status quo remains (ie bc doesn't belong in stage3) then there would be no issue about @system. 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. Nobody is intending to show a lack of respect for anybody. The whole point of having a mailing list is so that you don't have to CC every single developer on every single thread. Nobody is required to read -dev, but as was pointed out recently, claiming that you don't read -dev isn't really a good starting point for a complaint that you've been left out of something. [1] 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. So, do you have an opinion on this that you'd like to share? I think it makes more sense to discuss what the best path forward is rather than argue about who gets to make the decision. Believe it or not, the folks who are on the Council aren't really interested in micro-managing everything that goes on in Gentoo. However, as you pointed out, everybody is impacted by what is in the system set, and the way "everybody" in Gentoo decides on things is through the Council. The alternative is endless threads like this one. What's in stage3 also impacts "everybody". The point about micro-managing is a judgment call about how large the impact. In my judgment, adding bc to stage3 or keeping the status quo is not a big enough issue that releng can't decide on their own. While anything may come to the Council and be entertained by it (at the cost of time), it would be my position to motion that the issue be pushed back to releng for a decision. At that point the Council will effectively be deciding whether or not they agree with me, namely, that this issue really doesn't impact everyone sufficiently to be taken out of releng's hands. It is important that the Council reflect the body's sensibilities about what is significant and what isn't. If we start judging everything as having a "significant impact" and taking it from the respective teams, then we will be micro-managing despite our words to the contrary. Jorge's response "than the council members should be ready to start doing Releng work" would not be atypical if we start overstepping that line. Although, I must say, Jorge's is being little premature here, and I doubt the Council will act rashly. No, the members of the Council aren't aware of every detail of everything that happens with Gentoo, and they don't possess every skill collectively possessed by every member of the community. About the only thing the Council can claim is that people voted for them to represent the community, so it functions best when we actually act like a community. [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20140408-summary.txt -- Rich -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Add bc back to the stage3
On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto wrote: > > 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. I don't think many really care about deferring to releng on what is in the stages. My concern is what is in @system, since that has a big impact on everybody. > 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. Nobody is intending to show a lack of respect for anybody. The whole point of having a mailing list is so that you don't have to CC every single developer on every single thread. Nobody is required to read -dev, but as was pointed out recently, claiming that you don't read -dev isn't really a good starting point for a complaint that you've been left out of something. [1] > 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. > So, do you have an opinion on this that you'd like to share? I think it makes more sense to discuss what the best path forward is rather than argue about who gets to make the decision. Believe it or not, the folks who are on the Council aren't really interested in micro-managing everything that goes on in Gentoo. However, as you pointed out, everybody is impacted by what is in the system set, and the way "everybody" in Gentoo decides on things is through the Council. The alternative is endless threads like this one. No, the members of the Council aren't aware of every detail of everything that happens with Gentoo, and they don't possess every skill collectively possessed by every member of the community. About the only thing the Council can claim is that people voted for them to represent the community, so it functions best when we actually act like a community. [1] - http://www.gentoo.org/proj/en/council/meeting-logs/20140408-summary.txt -- Rich
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)
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] 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
Re: [gentoo-dev] Add bc back to the stage3
On Sat, Sep 27, 2014 at 7:39 PM, 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. > I never said we have to have a council vote. However, any dev can ask for the Council to take up any agenda item. The Council can always choose to defer to another team. As of this moment, nobody has asked to put it on the agenda. However, putting it on the agenda is better than having a huge flamewar with no resolution. I don't think the Council needs to vote on individual packages being in/out of @system and so on, but it does make sense for the Council to decide the guidelines for what does go in. There is a big debate here about whether @system should be a collection of useful stuff, or a minimal set of core dependencies, etc. That seems like a topic worth discussing to me... -- Rich
Re: [gentoo-dev] Add bc back to the stage3
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. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Add bc back to the stage3
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
Re: [gentoo-dev] Add bc back to the stage3
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! 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.
Re: [gentoo-dev] Add bc back to the stage3
Kent Fredric: > On 28 September 2014 00:22, Ciaran McCreesh > wrote: > >> >> I agree. It's time to replace nano with Vim. > > > > http://i.imgur.com/qRNTQGi.png > We need a moderated development mailing list.
Re: [gentoo-dev] Add bc back to the stage3
On 09/27/14 11:19, Mike Gilbert wrote: On Sat, Sep 27, 2014 at 8:22 AM, 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. To restate this: There are numerous other utilities specified in POSIX which we do not have in @system (or the stage3 tarball). Agreed. The argument "its posix and should be in there" doesn't fit the criterion for a stage3 tarball. A stage3 should be "a minimal set from which any gentoo system can be built" (modulo arch, abi, libc, ..., of course.) Emerging any linux kernel package will pull in bc (see REDEPEND in kernel-2.eclass) and therefore bc is not needed to complete that minimal set. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Add bc back to the stage3
On Sat, Sep 27, 2014 at 8:22 AM, 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. > To restate this: There are numerous other utilities specified in POSIX which we do not have in @system (or the stage3 tarball).
Re: [gentoo-dev] Add bc back to the stage3
On 28 September 2014 00:22, Ciaran McCreesh wrote: > > I agree. It's time to replace nano with Vim. http://i.imgur.com/qRNTQGi.png -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Add bc back to the stage3
On 27 September 2014 20:40, Ciaran McCreesh wrote: > On Sat, 27 Sep 2014 18:31:03 +0600 > Vladimir Romanov wrote: >> Em. I don't agree. I prefer Emacs and don't like Vim. But if i must >> choose between Vim and Nano, i prefer Nano > > But vi is POSIX. vi is available through busybox already -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Add bc back to the stage3
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. lu
Re: [gentoo-dev] Add bc back to the stage3
Well, if vi is posix, and it is so important, then you may use it. But please, don't delete nano. 2014-09-27 18:40 GMT+06:00 Ciaran McCreesh : > On Sat, 27 Sep 2014 18:31:03 +0600 > Vladimir Romanov wrote: > > Em. I don't agree. I prefer Emacs and don't like Vim. But if i must > > choose between Vim and Nano, i prefer Nano > > But vi is POSIX. > > -- > Ciaran McCreesh >
Re: [gentoo-dev] Add bc back to the stage3
On Sat, 27 Sep 2014 18:31:03 +0600 Vladimir Romanov wrote: > Em. I don't agree. I prefer Emacs and don't like Vim. But if i must > choose between Vim and Nano, i prefer Nano But vi is POSIX. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Add bc back to the stage3
Em. I don't agree. I prefer Emacs and don't like Vim. But if i must choose between Vim and Nano, i prefer Nano 2014-09-27 18:22 GMT+06:00 Ciaran McCreesh : > 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. > > -- > Ciaran McCreesh >
Re: [gentoo-dev] Add bc back to the stage3
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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Add bc back to the stage3
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). lu
Re: [gentoo-dev] Add bc back to the stage3
On 09/17/14 10:13, Samuli Suominen wrote: On 17/09/14 16:29, Alan McKinnon wrote: On 17/09/2014 14:49, Aaron W. Swenson wrote: On 2014-09-17 14:20, viv...@gmail.com wrote: Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: 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? Most people don't use the ebuild for the kernel That's a rather outrageous and difficult to substantiate claim. Given what I've seen in the forums and on IRC, it would appear the reverse is true; most people use the ebuild for the kernel. I wouldn't consider people who deviate from the supported methods as our concern. If you're smart enough to do that and want to make your own path, you're smart enough to emerge bc. Agreed. I've been on -user for 10+ years and only a very few fetch their kernels directly from upstream. The vast majority of users who have described how they do it simply emerge one of the source packages just like the handbook says to do. There's an even split between genkernel users and those who make menuconfig (100% unscientific survey taken from my brain and nowhere else) I've never used gentoo-sources in my life, and always fetched sources by hand from kernel.org, but, at the same time, I find it's 100% my own responsibility to cover any fallout from that, including manually emerging required dependencies. - Samuli I agree. Anyone is free to build and install anything without the ebuild, but then they're on their own. Also, who says we're building a linux kernel with our stage3s? I may want on just as a chroot or container, or run it on a non-linux kernel. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Add bc back to the stage3
On 17/09/14 16:29, Alan McKinnon wrote: > On 17/09/2014 14:49, Aaron W. Swenson wrote: >> On 2014-09-17 14:20, viv...@gmail.com wrote: >>> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: 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? >>> Most people don't use the ebuild for the kernel >> That's a rather outrageous and difficult to substantiate claim. Given >> what I've seen in the forums and on IRC, it would appear the reverse >> is true; most people use the ebuild for the kernel. >> >> I wouldn't consider people who deviate from the supported methods as >> our concern. If you're smart enough to do that and want to make your >> own path, you're smart enough to emerge bc. >> > > Agreed. I've been on -user for 10+ years and only a very few fetch their > kernels directly from upstream. The vast majority of users who have > described how they do it simply emerge one of the source packages just > like the handbook says to do. > > There's an even split between genkernel users and those who make > menuconfig (100% unscientific survey taken from my brain and nowhere else) > > > I've never used gentoo-sources in my life, and always fetched sources by hand from kernel.org, but, at the same time, I find it's 100% my own responsibility to cover any fallout from that, including manually emerging required dependencies. - Samuli
Re: [gentoo-dev] Add bc back to the stage3
On Wed, Sep 17, 2014 at 9:29 AM, Alan McKinnon wrote: > On 17/09/2014 14:49, Aaron W. Swenson wrote: > > Agreed. I've been on -user for 10+ years and only a very few fetch their > kernels directly from upstream. The vast majority of users who have > described how they do it simply emerge one of the source packages just > like the handbook says to do. > Agree. Lots of people install web applications by hand, but that doesn't mean that we should make every web development framework out there a dependency of apache. -- Rich
Re: [gentoo-dev] Add bc back to the stage3
On 17/09/2014 14:49, Aaron W. Swenson wrote: > On 2014-09-17 14:20, viv...@gmail.com wrote: >> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: >>> 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? >> >> Most people don't use the ebuild for the kernel > > That's a rather outrageous and difficult to substantiate claim. Given > what I've seen in the forums and on IRC, it would appear the reverse > is true; most people use the ebuild for the kernel. > > I wouldn't consider people who deviate from the supported methods as > our concern. If you're smart enough to do that and want to make your > own path, you're smart enough to emerge bc. > Agreed. I've been on -user for 10+ years and only a very few fetch their kernels directly from upstream. The vast majority of users who have described how they do it simply emerge one of the source packages just like the handbook says to do. There's an even split between genkernel users and those who make menuconfig (100% unscientific survey taken from my brain and nowhere else) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] Add bc back to the stage3
On 2014-09-17 14:20, viv...@gmail.com wrote: > Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: > > 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? > > Most people don't use the ebuild for the kernel That's a rather outrageous and difficult to substantiate claim. Given what I've seen in the forums and on IRC, it would appear the reverse is true; most people use the ebuild for the kernel. I wouldn't consider people who deviate from the supported methods as our concern. If you're smart enough to do that and want to make your own path, you're smart enough to emerge bc. -- Mr. Aaron W. Swenson Gentoo Linux Developer PostgreSQL Herd Bull Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 signature.asc Description: Digital signature
Re: [gentoo-dev] Add bc back to the stage3
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto: > 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? Most people don't use the ebuild for the kernel
Re: [gentoo-dev] Add bc back to the stage3
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? lu Regards, Jorge Manuel B. S. Vicetto Gentoo Developer
Re: [gentoo-dev] Add bc back to the stage3
On Tue, Sep 16, 2014 at 7:47 PM, Luca Barbato wrote: > The bc utility is part of the posix tools and it might be used to build > linux among the other stuff. > I'm fine with including useful utilities in the stage3s, as long as they don't go into the system set. We really need to get beyond equating the two. Otherwise our systems will become a jumble of stuff that somebody finds useful for something, and then when we remove some of it we'll get occasional breakage because nobody will declare them as dependencies. That just isn't in the spirit of Gentoo. The system set should only contain stuff that a large percentage of the tree needs to depend on (let's say more than 20%), or which is required to be available to bootstrap the rest of the tree. Once mix-in-like support is available, then profiles can be a dumping ground for anything anybody finds useful, and the more the merrier... -- Rich
[gentoo-dev] Add bc back to the stage3
The bc utility is part of the posix tools and it might be used to build linux among the other stuff. lu
