Date: Sun, 18 Feb 2024 14:41:33 +0300 From: Vasily Postnicov <shamaz.mazum@gmail.com> To: Aryeh Friedman <aryehfriedman@gmail.com> Cc: ports@freebsd.org Subject: Re: Re: FreeBSD ports community is broken Message-ID: <CADnZ6BktN7yhr_bOpOrP4GukwF78dttvT7Hgwj2s9gLi0w-nXg@mail.gmail.com> In-Reply-To: <CAGBxaXm0PsZRaJsPRxBTyAMxMhe%2BOU_cWErenm-upP0k0=thew@mail.gmail.com> References: <20240218015843.34c5d078@rimwks.local> <7q6ep7m2eee6yqtxftlwkhuwdkssd74vjow55txms7lkokazfu@grrqllhefges> <20240218174921.a8082649142dd43a469bebfa@dec.sakura.ne.jp> <4ekno7iwxvdlw4xeholcrxuuazmcstxkqyidrz27ni43lzu6wg@3ro6r5b2vhoi> <CAGBxaXnBTF=-V55pbQNJ5czRihAOZvAt53UNzzYT=bgBiqwQ0w@mail.gmail.com> <CALH631kcLJ9KFREovOQXmcbTi1Mbj_dCQuhBqLX%2BPbO6gKJj_w@mail.gmail.com> <CAGBxaXm0PsZRaJsPRxBTyAMxMhe%2BOU_cWErenm-upP0k0=thew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000003737140611a676d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My 50 cents about poudriere: it's definitely not a machine-killer. Just remember to disable tmpfs for too heavy ports (my list includes rust, 0ad, webengine), start with only two jobs (one job is bad because the build can be blocked by fetching or packaging) and set ALLOW_MAKE_JOBS=3Dyes. This configuration works fine and without swap consumption on my 32GB computer. Another improvement: set MAKE_JOBS_NUMBER to a half of available cores. This way (two jobs each using n/2 cores) you can map your build processes to all available cores. =D0=B2=D1=81, 18 =D1=84=D0=B5=D0=B2=D1=80. 2024 =D0=B3., 14:18 Aryeh Friedm= an <aryehfriedman@gmail.com>: > On Sun, Feb 18, 2024 at 6:11=E2=80=AFAM Gleb Popov <arrowd@freebsd.org> w= rote: > > > > On Sun, Feb 18, 2024 at 1:37=E2=80=AFPM Aryeh Friedman <aryehfriedman@g= mail.com> > wrote: > > > > > > On Sun, Feb 18, 2024 at 5:16=E2=80=AFAM Felix Palmen <zirias@freebsd.= org> > wrote: > > > > > > > > * Tomoaki AOKI <junchoon@dec.sakura.ne.jp> [20240218 17:49]: > > > > > [a lot about automotive regulations] > > > > > > > > That's a nice example how comparisons of entirely different domains > > > > almost always go completely wrong. > > > > > > I guess you have never heard of software engineering? > > > > > > Also the OP is 100% right there is a lot of "brokenish" in the ports > > > community for example no maintainer should ever be banned from -ports= @ > > > but I have been for reasons never explained to me and thus am at a > > > severe disadvantage when asking for help (like how to switch from yac= c > > > to bison without errors and such). > > > > > > > > > > > To start with, cars (and especially individual parts) typically > aren't > > > > subject to consumer customizations, and if they are, it's way outsi= de > > > > the manufacturer's responsibility. Here, we were talking about > breakage > > > > that only happened when you customized your port builds. We aren't > > > > talking about security-relevant breakage either. > > > > > > Yes they are customized all the time. What do you think "options"? > > > (same for planes.) > > > > > > And sadly (speaking as the maintainer of 3 different ports > > > [devel/aegis, devel/fhist, devel/tailor and when I get time to > > > unbreaking it and taking maintership devel/cook]) there has to good > > > customizations that can be done after market without breaking the > > > ports (for example we use the actual tools above significantly then > > > how they where designed to be used but due to being the maintainer > > > still need to maintain the orginal behavior also) > > > > > > > > > > > > > > As explained in the PR as well, of course we add (temporary) > workarounds > > > > to *individual* ports when it seems necessary. We certainly don't a= dd > > > > workarounds to the framework itself unless it's perfectly clear the= re > > > > will be no other way. Not even considering yet that just fiddling > with > > > > CFLAGS has the potential to break a lot of other things when done > > > > globally. > > > > > > The framework has been broken for a long time. It should not require > > > prodiere running on a supermassive machine to work (in many cases > > > portmaster and make install recursion fail where prodiere works). > > > > It does not. The thing is: contributor submissions should be buildable > > in Poudriere because this is the way official packages are produced. > > You are free to build on the host locally, but it hides some errors > > which then break the build on our cluster. Without Poudriere you just > > have to be more cautious and perform more thorough testing. > > Wonderful: Are we now moving to the binary pkg only for mere mortals > then. For example my desktop is a fairly standard 12 core machine > with 24 GB of RAM and plenty of disk space (on SSD's) but yet Proudrie > slows the machine down so much that xorg becomes unresponsive or the > machine used for any other purpose (yes I know this can be customized > to make it work but that *SHOULD NOT* be the default case). One > reason I started with FreeBSD in the first place and not linsucks is > it is/(was?!?!?) completely buildable from source (including 3d party > packages) on a completely normal desktop (at least til about 2018 and > I started using FreeBSD in 1993). > > So when is it going to be possible for a mere mortal like the machine > above to use portmaster or recursive make install since Poudrie is a > machine killer > > --0000000000003737140611a676d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">My 50 cents about poudriere: it's definitely not a ma= chine-killer. Just remember to disable tmpfs for too heavy ports (my list i= ncludes rust, 0ad, webengine), start with only two jobs (one job is bad bec= ause the build can be blocked by fetching or packaging) and set ALLOW_MAKE_= JOBS=3Dyes.<div dir=3D"auto"><br></div><div dir=3D"auto">This configuration= works fine and without swap consumption on my 32GB computer.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">Another improvement: set MAKE_JOBS_NU= MBER to a half of available cores. This way (two jobs each using n/2 cores)= you can map your build processes to all available cores.</div></div><br><d= iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=D0=B2=D1=81= , 18 =D1=84=D0=B5=D0=B2=D1=80. 2024 =D0=B3., 14:18 Aryeh Friedman <<a hr= ef=3D"mailto:aryehfriedman@gmail.com">aryehfriedman@gmail.com</a>>:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex">On Sun, Feb 18, 2024 at 6:11=E2=80=AFAM= Gleb Popov <<a href=3D"mailto:arrowd@freebsd.org" target=3D"_blank" rel= =3D"noreferrer">arrowd@freebsd.org</a>> wrote:<br> ><br> > On Sun, Feb 18, 2024 at 1:37=E2=80=AFPM Aryeh Friedman <<a href=3D"= mailto:aryehfriedman@gmail.com" target=3D"_blank" rel=3D"noreferrer">aryehf= riedman@gmail.com</a>> wrote:<br> > ><br> > > On Sun, Feb 18, 2024 at 5:16=E2=80=AFAM Felix Palmen <<a href= =3D"mailto:zirias@freebsd.org" target=3D"_blank" rel=3D"noreferrer">zirias@= freebsd.org</a>> wrote:<br> > > ><br> > > > * Tomoaki AOKI <<a href=3D"mailto:junchoon@dec.sakura.ne.= jp" target=3D"_blank" rel=3D"noreferrer">junchoon@dec.sakura.ne.jp</a>> = [20240218 17:49]:<br> > > > > [a lot about automotive regulations]<br> > > ><br> > > > That's a nice example how comparisons of entirely differ= ent domains<br> > > > almost always go completely wrong.<br> > ><br> > > I guess you have never heard of software engineering?<br> > ><br> > > Also the OP is 100% right there is a lot of "brokenish"= in the ports<br> > > community for example no maintainer should ever be banned from -p= orts@<br> > > but I have been for reasons never explained to me and thus am at = a<br> > > severe disadvantage when asking for help (like how to switch from= yacc<br> > > to bison without errors and such).<br> > ><br> > > ><br> > > > To start with, cars (and especially individual parts) typica= lly aren't<br> > > > subject to consumer customizations, and if they are, it'= s way outside<br> > > > the manufacturer's responsibility.=C2=A0 Here, we were t= alking about breakage<br> > > > that only happened when you customized your port builds. We = aren't<br> > > > talking about security-relevant breakage either.<br> > ><br> > > Yes they are customized all the time. What do you think "opt= ions"?<br> > > (same for planes.)<br> > ><br> > > And sadly (speaking as the maintainer of 3 different ports<br> > > [devel/aegis, devel/fhist, devel/tailor and when I get time to<br= > > > unbreaking it and taking maintership devel/cook]) there has to go= od<br> > > customizations that can be done after market without breaking the= <br> > > ports (for example we use the actual tools above significantly th= en<br> > > how they where designed to be used but due to being the maintaine= r<br> > > still need to maintain the orginal behavior also)<br> > ><br> > ><br> > > ><br> > > > As explained in the PR as well, of course we add (temporary)= workarounds<br> > > > to *individual* ports when it seems necessary. We certainly = don't add<br> > > > workarounds to the framework itself unless it's perfectl= y clear there<br> > > > will be no other way. Not even considering yet that just fid= dling with<br> > > > CFLAGS has the potential to break a lot of other things when= done<br> > > > globally.<br> > ><br> > > The framework has been broken for a long time. It should not requ= ire<br> > > prodiere running on a supermassive machine to work (in many cases= <br> > > portmaster and make install recursion fail where prodiere works).= <br> ><br> > It does not. The thing is: contributor submissions should be buildable= <br> > in Poudriere because this is the way official packages are produced.<b= r> > You are free to build on the host locally, but it hides some errors<br= > > which then break the build on our cluster. Without Poudriere you just<= br> > have to be more cautious and perform more thorough testing.<br> <br> Wonderful: Are we now moving to the binary pkg only for mere mortals<br> then.=C2=A0 For example my desktop is a fairly standard 12 core machine<br> with 24 GB of RAM and plenty of disk space (on SSD's) but yet Proudrie<= br> slows the machine down so much that xorg becomes unresponsive or the<br> machine used for any other purpose (yes I know this can be customized<br> to make it work but that *SHOULD NOT* be the default case).=C2=A0 =C2=A0One= <br> reason I started with FreeBSD in the first place and not linsucks is<br> it is/(was?!?!?) completely buildable from source (including 3d party<br> packages) on a completely normal desktop (at least til about 2018 and<br> I started using FreeBSD in 1993).<br> <br> So when is it going to be possible for a mere mortal like the machine<br> above to use portmaster or recursive make install since Poudrie is a<br> machine killer<br> <br> </blockquote></div> --0000000000003737140611a676d7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADnZ6BktN7yhr_bOpOrP4GukwF78dttvT7Hgwj2s9gLi0w-nXg>