Re: Getting off topic (Re: portmaster, portupgrade, etc)

[Alexander Leidinger]

Quoting Baptiste Daroussin  (from Fri, 6 Oct 2017  
15:34:58 +0200):



Speaking solely for myself, I am more than pleased by all the work
Baptiste and fellow developers have put into the ports infrastructure.
THANK YOU!  But also, portmaster is a life saver for me with my 4GB
build machine, so I hope I can participate in reviving it.  -- George



Thank you,

I will be more than happy to merge patches in
https://github.com/freebsd/portmaster which makes it handle flavors


Given that there is a pull request for better pkg support (and xz  
support for packages) from 2014, would it make sense to give more  
people/committers write access there? Or to move it into the FreeBSD  
svn (projects/...)?


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpZWPHWAE_U8.pgp
Description: Digitale PGP-Signatur

Re: portmaster, portupgrade, etc

[Chris H]

On Fri, 6 Oct 2017 18:46:08 +1100 (EST) Dave Horsfall  wrote

> On Thu, 5 Oct 2017, Chris H wrote:
> 
> >> I'll second that.-- George (old fart w/50 years software experience)
> >
> > WooHoo! another greybeard! I'm at ~50yrs myself!
> 
> Only 47 years exp here (the last 42 with Unix).
..and Unix *exists* because of some whom are now "old farts" || "greybeards"!
:)

--Chris
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer." ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Getting off topic (Re: portmaster, portupgrade, etc)

[Baptiste Daroussin]

On Fri, Oct 06, 2017 at 01:28:59PM +, George Mitchell wrote:
> On 10/06/17 04:20, Baptiste Daroussin wrote:
> > On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
> >> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
> >>> On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
>  On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> >
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
> 
>  Please include a discussion on how to use poudriere on
>  a system with limited resouces (e.g., 10 GB of free
>  diskspace and less than 1 GB free memory).  I know
>  portmaster works well [1] within an environment with
>  only 4 GB free diskspace and 1 GB memory.
> 
>  [1] portmaster worked well prior to portmgr's decision
>  to displace simple small tools in favor of a sledge
>  hammer.
> >>>
> >>> FUD.. portmgr never took any decision like this.
> >>> The problem with portmaster (beside some design flows regarding
> >>> the "not build in a clean room") is that it is not maintained anymore.
> >>> (Note that it has never been maintained by portmgr at all).
> >>
> >> I'm well aware of Doug Barton's history with FreeBSD.  You
> >> can paint it with whatever color you want.
> >>
> >> If you (and other poudriere) contributors stated that flavors/subpackages
> >> would not be supported by poudriere, would flavors/subpackages been
> >> wedged into the ports build infrastructure?
> > 
> > Yes because if you look at mailing lists etc, you ould have figured out that
> > this is the number one feature requested in the ports tree for years.
> > 
> > Also yes we would have make sure that the tools used to build official 
> > packages
> > would have worked with it, prior poudriere it was tinderbox.
> > 
> > And again we are giving time (and warning in advance) for all the tools to 
> > catch
> > up!
> > 
> > Best regards,
> > Bapt
> > 
> Speaking solely for myself, I am more than pleased by all the work
> Baptiste and fellow developers have put into the ports infrastructure.
> THANK YOU!  But also, portmaster is a life saver for me with my 4GB
> build machine, so I hope I can participate in reviving it.  -- George
> 

Thank you,

I will be more than happy to merge patches in
https://github.com/freebsd/portmaster which makes it handle flavors

Best regards,
Bapt


signature.asc
Description: PGP signature

Getting off topic (Re: portmaster, portupgrade, etc)

[George Mitchell]

On 10/06/17 04:20, Baptiste Daroussin wrote:
> On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
>> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
>>> On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
 On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
>
> Poudriere really needs its own small book. Yes, you can do simple
> poudriere installs, but once you start covering it properly the docs
> quickly expand. My notes alone are longer than my af3e chapter
> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> 2018).

 Please include a discussion on how to use poudriere on
 a system with limited resouces (e.g., 10 GB of free
 diskspace and less than 1 GB free memory).  I know
 portmaster works well [1] within an environment with
 only 4 GB free diskspace and 1 GB memory.

 [1] portmaster worked well prior to portmgr's decision
 to displace simple small tools in favor of a sledge
 hammer.
>>>
>>> FUD.. portmgr never took any decision like this.
>>> The problem with portmaster (beside some design flows regarding
>>> the "not build in a clean room") is that it is not maintained anymore.
>>> (Note that it has never been maintained by portmgr at all).
>>
>> I'm well aware of Doug Barton's history with FreeBSD.  You
>> can paint it with whatever color you want.
>>
>> If you (and other poudriere) contributors stated that flavors/subpackages
>> would not be supported by poudriere, would flavors/subpackages been
>> wedged into the ports build infrastructure?
> 
> Yes because if you look at mailing lists etc, you ould have figured out that
> this is the number one feature requested in the ports tree for years.
> 
> Also yes we would have make sure that the tools used to build official 
> packages
> would have worked with it, prior poudriere it was tinderbox.
> 
> And again we are giving time (and warning in advance) for all the tools to 
> catch
> up!
> 
> Best regards,
> Bapt
> 
Speaking solely for myself, I am more than pleased by all the work
Baptiste and fellow developers have put into the ports infrastructure.
THANK YOU!  But also, portmaster is a life saver for me with my 4GB
build machine, so I hope I can participate in reviving it.  -- George



signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Thu, Oct 05, 2017 at 10:08:54PM +, Baho Utot wrote:
> 
> 
> On 10/05/17 16:27, Grzegorz Junka wrote:
> > 
> > On 05/10/2017 19:54, Baho Utot wrote:
> > > 
> > > 
> > > On 10/04/17 16:39, Ernie Luzar wrote:
> > > 
> > > > Here's my take on that.
> > > > 
> > > > The future direction has already been decided by the FreeBSD
> > > > leaders 2 years ago with their development of a better pkg
> > > > system.
> > > > 
> > > 
> > > [putolin]
> > > 
> > > > Don't let the few old school die hearts who are afraid of any
> > > > change and make the most noise influence you. There will always
> > > > be edge case user who think their needs out weight what is best
> > > > for the group.
> > > 
> > > So what you are really saying is Go to hell old farts we don't need
> > > you here.  We are not going to listen to you as you are too old to
> > > know anything.  You are old and stupid.
> > > 
> > > It is looking like I will need to move away from FreeBSD if that is
> > > really what is being accomplished here.
> > 
> > But do those old farts have anything interesting to say or they are just
> > making noise? What's the alternative to the proposed direction?
> > 
> > GrzegorzJ
> 
> Everyone should be heard.  who knows if the direction would be the same?
> 
> You won't hear from this old fart as every time I have had a question or
> input on direction All I got was grief.
> 
> The last time was about pkgng.  As someone that moved from LFS/building my
> own distribution to FreeBSD, and adding a package manager and tools for LFS.
> I think I may have learned something in that process.  SO what did you folks
> do, Well I was just bitch slapped down.  So much for user input.  Hell pkgng
> can not even merge configurations file in /etc when is that going to be
> fixed.
It can... and for a while, the fact it is not used in packaging base is another
subject, but the tool can definitly do it.

[...]
> 
> Anyway it looks like I will be moving to OpenBSD or just go back to rolling
> my own as I have more free time to pursue building systems that work for me.
> FreeBSD just doesn't look like it will be a fit for me in the future.

Have you figured out that OpenBSD is a step further in the direction you are
rejecting: They have FLAVORS for decades and they do strongly recommend users to
use binary packages in the first place... Just sating...

Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Mike Clarke]

On Friday 06 Oct 2017 00:29:17 tech-lists wrote:

> I'd use packages more were it not for the received wisdom that mixing
> packages and ports is a Bad Thing (tm) - is this still the case? 

The main thing is to keep your ports tree synchronised with the version used 
for the 
package repository. I find that the script at 
https://gist.github.com/reedacartwright/8622973baf89b263a6d7 is a useful tool 
for 
this. The script hasn't been updated beyond 10.x-RELEASE so if you're running 
11.x-
RELEASE you need to patch the script by adding the following line:

110amd64-default)   PKG_SERVER=beefy9.nyi.freebsd.org ;;

If only pkg could be made to report the revision number of the ports tree it 
was built 
from we wouldn't need to hunt around for this information.

-- 
Mike Clarke
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Fri, Oct 06, 2017 at 08:13:42AM +, Steve Kargl wrote:
> On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
> > On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> > > On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > > > 
> > > > Poudriere really needs its own small book. Yes, you can do simple
> > > > poudriere installs, but once you start covering it properly the docs
> > > > quickly expand. My notes alone are longer than my af3e chapter
> > > > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > > > 2018).
> > > 
> > > Please include a discussion on how to use poudriere on
> > > a system with limited resouces (e.g., 10 GB of free
> > > diskspace and less than 1 GB free memory).  I know
> > > portmaster works well [1] within an environment with
> > > only 4 GB free diskspace and 1 GB memory.
> > > 
> > > [1] portmaster worked well prior to portmgr's decision
> > > to displace simple small tools in favor of a sledge
> > > hammer.
> > 
> > FUD.. portmgr never took any decision like this.
> > The problem with portmaster (beside some design flows regarding
> > the "not build in a clean room") is that it is not maintained anymore.
> > (Note that it has never been maintained by portmgr at all).
> 
> I'm well aware of Doug Barton's history with FreeBSD.  You
> can paint it with whatever color you want.
> 
> If you (and other poudriere) contributors stated that flavors/subpackages
> would not be supported by poudriere, would flavors/subpackages been
> wedged into the ports build infrastructure?

Yes because if you look at mailing lists etc, you ould have figured out that
this is the number one feature requested in the ports tree for years.

Also yes we would have make sure that the tools used to build official packages
would have worked with it, prior poudriere it was tinderbox.

And again we are giving time (and warning in advance) for all the tools to catch
up!

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Fri, Oct 06, 2017 at 09:41:28AM +0200, Baptiste Daroussin wrote:
> On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> > On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > > 
> > > Poudriere really needs its own small book. Yes, you can do simple
> > > poudriere installs, but once you start covering it properly the docs
> > > quickly expand. My notes alone are longer than my af3e chapter
> > > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > > 2018).
> > 
> > Please include a discussion on how to use poudriere on
> > a system with limited resouces (e.g., 10 GB of free
> > diskspace and less than 1 GB free memory).  I know
> > portmaster works well [1] within an environment with
> > only 4 GB free diskspace and 1 GB memory.
> > 
> > [1] portmaster worked well prior to portmgr's decision
> > to displace simple small tools in favor of a sledge
> > hammer.
> 
> FUD.. portmgr never took any decision like this.
> The problem with portmaster (beside some design flows regarding
> the "not build in a clean room") is that it is not maintained anymore.
> (Note that it has never been maintained by portmgr at all).

I'm well aware of Doug Barton's history with FreeBSD.  You
can paint it with whatever color you want.

If you (and other poudriere) contributors stated that flavors/subpackages
would not be supported by poudriere, would flavors/subpackages been
wedged into the ports build infrastructure?

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Dave Horsfall]

On Thu, 5 Oct 2017, Chris H wrote:


I'll second that.-- George (old fart w/50 years software experience)


WooHoo! another greybeard! I'm at ~50yrs myself!


Only 47 years exp here (the last 42 with Unix).

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Baptiste Daroussin]

On Wed, Oct 04, 2017 at 05:15:18PM +, Steve Kargl wrote:
> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > 
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
> 
> Please include a discussion on how to use poudriere on
> a system with limited resouces (e.g., 10 GB of free
> diskspace and less than 1 GB free memory).  I know
> portmaster works well [1] within an environment with
> only 4 GB free diskspace and 1 GB memory.
> 
> [1] portmaster worked well prior to portmgr's decision
> to displace simple small tools in favor of a sledge
> hammer.

FUD.. portmgr never took any decision like this.
The problem with portmaster (beside some design flows regarding the "not build
in a clean room") is that it is not maintained anymore. (Note that it has never
been maintained by portmgr at all).

What this means is, when some highly needed features such as subpackages and
flavors are coming in it will just break. portmgr is taking that into account at
that is one of the reason we have decided to block the adoption of flavors for
some time to give time to people to catchup and fixup the tools they do
like/use (yes documentation and simple examples are coming soon(c)(tm).

This not only concerns portmaster but also portupgrade, tinderbox and ANY third
party tools that works on the ports tree directly.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: portmaster, portupgrade, etc

[Matthew Seaman]

On 06/10/2017 00:29, tech-lists wrote:
> On Thu, Oct 05, 2017 at 12:22:30PM +0100, Mike Clarke wrote:
> 
>> the currently available package is built against php56. Using
>> poudriere for this one task would
>> be equivalent to using a steamroller to crack a peanut. Building
>> phpMyAdmin from ports is no
>> great problem for me and perhaps future development of pkg might avoid
>> the need to build
>> my own version but I'd hope that documented methods will continue to
>> exist for users with
>> this type of need.

> I encountered exactly this issue a few days ago. Was suprised to find
> that I couldn't find phpmyadmin built against php70 in packages, so
> built php70
> then built phpmyadmin. This was easy just using the ports framework. I
> hope the ability to use the ports tree like this never disappears as
> it's one of freebsd's great strengths i think.
> I'd use packages more were it not for the received wisdom that mixing
> packages and ports is a Bad Thing (tm) - is this still the case?

Yes -- exactly.  As maintainer of phpMyAdmin I find these sort of
enquiries depressing.  phpMyAdmin gets built in the project repositories
with a dependency on the ports default version of PHP, but there are a
substantial group of people that would like to use a different version
of PHP who we cannot serve properly.

This is why we need FLAVOURS in the ports -- or in this case, actually
the solution would be better provided by variable dependencies. It's
particularly annoying in the case of phpMyAdmin since the process of
"building" the port is literally to copy the files into the staging area.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[Kurt Jaeger]

Hi!

> I'd vote to have Chris H be the maintainer of this port.
> Why knock the guy if he wants to invest his time and
> energy into doing something to help the project?
> Does it cause anyone pain to see someone working on
> maintaining the project? Why would someone say no you cannot maintain this
> port, especially when no one else is doing the work?

In general, if a port has a maintainer, the idea is that
that old maintainer is willing to hand over the port to the
new maintainer, because the new maintainer submits more and tested
patches etc.

I'm not implying anything about portmaster, just stating the
general idea.

> Who would stand up and say, no Chris you can't maintain the port and why?

Being listed or not being listed in the maintainer field of the
port Makefile does not change the problem of updates/patches. 

Someone has to provide patches, otherwise there's no progress.

Again, I'm not implying anything about portmaster, just stating the
general idea.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[blubee blubeeme]

I'd vote to have Chris H be the maintainer of this port.
Why knock the guy if he wants to invest his time and
energy into doing something to help the project?
Does it cause anyone pain to see someone working on
maintaining the project? Why would someone say no you cannot maintain this
port,
especially when no one else is doing the work?

The only best way I've ever seen to find a really good developer is
find someone with dedication and willingness to take on hard challenges and
stick to it.
Chris seems like that type of person,
who would deny the man a chance to donate his time to the FreeBSD project?

Who would stand up and say, no Chris you can't maintain the port and why?

On Fri, Oct 6, 2017 at 11:26 AM, Kurt Jaeger  wrote:

> Hi!
>
> > > a few inquiries regarding taking maintainer for the port. My request
> > > was ultimately declined. I was deemed unqualified. That judgement was
> > > unfounded. :(
>
> Right now, tz@ is the maintainer of ports-mgmt/portmaster.
>
> If someone wants to become maintainer, the best way is to
> look at the open PRs:
>
> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster
>
> verify their status and provide patches.
>
> --
> p...@opsec.eu+49 171 3101372 3 years to
> go !
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Kurt Jaeger]

Hi!

> > a few inquiries regarding taking maintainer for the port. My request
> > was ultimately declined. I was deemed unqualified. That judgement was
> > unfounded. :(

Right now, tz@ is the maintainer of ports-mgmt/portmaster.

If someone wants to become maintainer, the best way is to
look at the open PRs:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster

verify their status and provide patches.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 05 Oct 2017 15:37:08 -0700 "Chris H" wrote
> > > On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger wrote
---8<---8<---
> > > Seem a reasonable request? If [found] so, I'll solicit for qualified
> > > individuals to work with me on it in a new thread.
> > > 
> > > Thanks for your time, and consideration
> > 
> > Please reach out to tz first,
> Will do.

Done! Just awaiting his reply. :)

> > as he currently maintains the port. Portmaster
> > # Adam
> 
> --Chris

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 19:59:51 -0400 George Mitchell 
wrote

> On 10/05/17 18:13, Adam Weinberger wrote:
> >> [...]
> >> Seem a reasonable request? If [found] so, I'll solicit for qualified
> >> individuals to work with me on it in a new thread.
> >>
> >> Thanks for your time, and consideration
> > 
> > [...]
> > Let me know what you need. I'll give you whatever support I can.
> > 
> > # Adam
> > 
> > 
> I'll second that.-- George (old fart w/50 years software experience)

WooHoo! another greybeard! I'm at ~50yrs myself!

Thanks!

I'll propose the plan to Torsten, and get back to all your
generous offers!

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/05/17 18:13, Adam Weinberger wrote:
>> [...]
>> Seem a reasonable request? If [found] so, I'll solicit for qualified
>> individuals to work with me on it in a new thread.
>>
>> Thanks for your time, and consideration
> 
> [...]
> Let me know what you need. I'll give you whatever support I can.
> 
> # Adam
> 
> 
I'll second that.-- George (old fart w/50 years software experience)




signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[tech-lists]

On Thu, Oct 05, 2017 at 12:22:30PM +0100, Mike Clarke wrote:


the currently available package is built against php56. Using poudriere for 
this one task would
be equivalent to using a steamroller to crack a peanut. Building phpMyAdmin 
from ports is no
great problem for me and perhaps future development of pkg might avoid the need 
to build
my own version but I'd hope that documented methods will continue to exist for 
users with
this type of need.


I encountered exactly this issue a few days ago. Was suprised to find
that I couldn't find phpmyadmin built against php70 in packages, so built php70
then built phpmyadmin. This was easy just using the ports framework. I
hope the ability to use the ports tree like this never disappears as
it's one of freebsd's great strengths i think. 


I'd use packages more were it not for the received wisdom that mixing
packages and ports is a Bad Thing (tm) - is this still the case? 
--

J.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 22:59:31 + Grzegorz Junka  wrote

> On 05/10/2017 22:15, Chris H wrote:
> > On Thu, 5 Oct 2017 20:27:19 + Grzegorz Junka  wrote
> >
> >> On 05/10/2017 19:54, Baho Utot wrote:
> >>>
> >>> On 10/04/17 16:39, Ernie Luzar wrote:
> >>>
>  Here's my take on that.
> 
>  The future direction has already been decided by the FreeBSD leaders
>  2 years ago with their development of a better pkg system.
> 
> >>> [putolin]
> >>>
>  Don't let the few old school die hearts who are afraid of any change
>  and make the most noise influence you. There will always be edge case
>  user who think their needs out weight what is best for the group.
> >>> So what you are really saying is Go to hell old farts we don't need
> >>> you here.  We are not going to listen to you as you are too old to
> >>> know anything.  You are old and stupid.
> >>>
> >>> It is looking like I will need to move away from FreeBSD if that is
> >>> really what is being accomplished here.
> >> But do those old farts have anything interesting to say or they are just
> >> making noise? What's the alternative to the proposed direction?\
> > This is an *extremely* difficult question to answer, and these discussions
> > come up all too often. The short answer is; shut up and code! -- Meaning;
> > since FreeBSD exists, and grows because of those whom are willing to
> > produce code to accomplish it. Those who put their code, where their
> > mouth is, will be the deciding vote. :)
> > I'm not always loving it. But it is, what it is, and it's hard to argue
> > with it. No? :)
> 
> Yes and no. You are absolutely right that those able to code will have 
> an advantage over those who just shout at others but do nothing, even if 
> those who code don't do exactly what those who shout would like them to 
> do. But that's shortsighted. There are better ways of spending time than 
> developing something that no one else is going to use.
> 
> FreeBSD exists for its users. This doesn't mean those who shout the 
> loudest or those with esoteric needs that no one has time to cater for. 
> This means the 90% who are not even subscribed to this list or the 99% 
> who have never expressed their opinion about the direction FreeBSD 
> should take either on this list or anywhere else (the silent majority).
> 
> They vote for the proposed direction either by adopting FreeBSD and 
> spreading the word around, or by abandoning it and moving to other 
> systems without expressing any complaints. That's the reality.
> 
> Now, from that perspective it doesn't really matter if portmaster is 
> maintained or not. What does matter is if the proposed changes to pkg 
> and the ports system are going to make the life of an average user 
> easier or not. Everything else should be secondary.
Like I said; I'm not always loving it.
and I'm not attempting to argue with you. :)
But in the end. Those who put their code where their mouth is,
almost always win the argument.
Tho, when /enough/ non-coders speak up. That can also make a
difference too. :)

> 
> GrzegorzJ
--Chris
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:15, Chris H wrote:

On Thu, 5 Oct 2017 20:27:19 + Grzegorz Junka  wrote


On 05/10/2017 19:54, Baho Utot wrote:


On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders
2 years ago with their development of a better pkg system.


[putolin]


Don't let the few old school die hearts who are afraid of any change
and make the most noise influence you. There will always be edge case
user who think their needs out weight what is best for the group.

So what you are really saying is Go to hell old farts we don't need
you here.  We are not going to listen to you as you are too old to
know anything.  You are old and stupid.

It is looking like I will need to move away from FreeBSD if that is
really what is being accomplished here.

But do those old farts have anything interesting to say or they are just
making noise? What's the alternative to the proposed direction?\

This is an *extremely* difficult question to answer, and these discussions
come up all too often. The short answer is; shut up and code! -- Meaning;
since FreeBSD exists, and grows because of those whom are willing to
produce code to accomplish it. Those who put their code, where their
mouth is, will be the deciding vote. :)
I'm not always loving it. But it is, what it is, and it's hard to argue
with it. No? :)


Yes and no. You are absolutely right that those able to code will have 
an advantage over those who just shout at others but do nothing, even if 
those who code don't do exactly what those who shout would like them to 
do. But that's shortsighted. There are better ways of spending time than 
developing something that no one else is going to use.


FreeBSD exists for its users. This doesn't mean those who shout the 
loudest or those with esoteric needs that no one has time to cater for. 
This means the 90% who are not even subscribed to this list or the 99% 
who have never expressed their opinion about the direction FreeBSD 
should take either on this list or anywhere else (the silent majority).


They vote for the proposed direction either by adopting FreeBSD and 
spreading the word around, or by abandoning it and moving to other 
systems without expressing any complaints. That's the reality.


Now, from that perspective it doesn't really matter if portmaster is 
maintained or not. What does matter is if the proposed changes to pkg 
and the ports system are going to make the life of an average user 
easier or not. Everything else should be secondary.


GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:27, Chris H wrote:

On Thu, 5 Oct 2017 22:05:05 + Grzegorz Junka  wrote


On 05/10/2017 21:53, Chris H wrote:

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote


On 5 Oct, 2017, at 10:28, Steve Kargl 
wrote:
On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:

On 5 Oct, 2017, at 9:25, Steve Kargl 
wrote: Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to
libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr
merely brings new features to the ports tree. Portmgr itself is
responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but
portmgr is not killing off portmaster. There is simply nobody
developing portmaster anymore, and that is not portmgr's
responsibility. There ARE people developing poudriere, and
that is why poudriere continues to work with new ports tree features.


I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.

Not quite. It works in the other direction. Ports isn't designed for
poudriere. Poudriere is designed for ports. 100% of the flavours
development is happening in public. Anybody who wishes to work on
portmaster can participate in the process too.

I think you have a misperception of the relationship between portmgr and
poudriere. The coming flavours would break poudriere too, except there are
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and
I don't get the impression that I'm going to change your mind. All I can
tell you is that impending portmaster breakage is NOT by design, and is
only happening because portmaster isn't actively developed anymore. If
you'd like to believe in secret poudriere cabals and anti-portmaster
conspiracies, that's up to you.

# Adam

While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for

What does it mean in practical terms? A list of signatories under your
candidature and a recommendation letter? Endorsements sent to a
particular email?

I don't quite understand why would anybody want to decline a request to
maintain a port that is unmaintained otherwise? Are they expecting
better candidatures? I would understand if they had 10 

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 16:13:36 -0600 Adam Weinberger  wrote

> > On 5 Oct, 2017, at 15:53, Chris H  wrote:
> > 
> > On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote
> > 
> >>> On 5 Oct, 2017, at 10:28, Steve Kargl 
> >>> wrote: 
> >>> On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> > On 5 Oct, 2017, at 9:25, Steve Kargl 
> > wrote: Which brings me back to my i686 laptop with limited resources.
> > If portmgr makes it impractical/impossible to easily install ports
> > without a sledge hammer, then testing possible future patches to 
> > libm will simply skip i686 class hardware.
>  
>  I'm not clear what role you think portmgr has in this. Portmgr
>  merely brings new features to the ports tree. Portmgr itself is
>  responsible for no build tool other than "make install".
>  
>  I don't know how many times I need to keep saying this, but
>  portmgr is not killing off portmaster. There is simply nobody
>  developing portmaster anymore, and that is not portmgr's
>  responsibility. There ARE people developing poudriere, and
>  that is why poudriere continues to work with new ports tree features.
>  
> >>> 
> >>> I suppose it's a matter of semantics.  If the Makefiles and *.mk
> >>> files under /usr/ports are altered to allow subpackages and
> >>> flavours to enhance pkg and poudriere, which will break portmaster
> >>> further, then yes portmgr has made a decision to endorse a sledge
> >>> hammer over simple tools.
> >>> 
> >>> Mere users of the ports collection are not privy to discussions
> >>> on a portmgr alias/mailinglist.  A quick scan of the members of 
> >>> portmgr and contributors to poudriere show at least 4 common
> >>> members.  There are 8 people listed under portmgr.  When decisions
> >>> were being made on the introduction of subpackages/flavours into
> >>> the ports collection, did the 4 common members recluse themselves
> >>> from any formal or informal vote?  If no, then there is certainly
> >>> a conflict-of-interest in what is best for the ports collection
> >>> versus what is best for poudriere.
> >>> 
> >>> Yes, portmaster is currently unmaintained.  Doug Barton left
> >>> FreeBSD developement because he was continually brow beaten
> >>> whenever he pointed out what he felt were (serious) flaws in
> >>> FreeBSD and in the ports collection.
> >> 
> >> Not quite. It works in the other direction. Ports isn't designed for
> >> poudriere. Poudriere is designed for ports. 100% of the flavours
> >> development is happening in public. Anybody who wishes to work on
> >> portmaster can participate in the process too. 
> >> 
> >> I think you have a misperception of the relationship between portmgr and
> >> poudriere. The coming flavours would break poudriere too, except there are
> >> people actively developing it. 
> >> 
> >> You seem to be fully convinced in a conspiracy to destroy portmaster, and
> >> I don't get the impression that I'm going to change your mind. All I can
> >> tell you is that impending portmaster breakage is NOT by design, and is
> >> only happening because portmaster isn't actively developed anymore. If
> >> you'd like to believe in secret poudriere cabals and anti-portmaster
> >> conspiracies, that's up to you. 
> >> 
> >> # Adam
> > While I have no intention to speak on Steve's behalf. I /would/ like
> > to speak in his humble defense;
> > over year ago, I attempted to become maintainer for
> > ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
> > it's value, and 2) it had been scorned for some time, and there were
> > /many/ discussions to have it removed. At the time I attempted the
> > request, it had not "officially" had a maintainer, and there was
> > serious talk as to /really/ having it removed from the ports tree.
> > bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
> > mailing list for portmaster /will/ show /many/ heated discussions
> > regarding it's removal -- this thread included. In any event, after
> > a few inquiries regarding taking maintainer for the port. My request
> > was ultimately declined. I was deemed unqualified. That judgement was
> > unfounded. :(
> 
> I remember that. I have to admit, I was pretty shocked by it as well.
> 
> > Granted, maintenance of portmaster is no small feat -- it's an
> > enormous scriptbal. But now some months later, I am maintainer for
> > ~120 ports! perform a search for portmaster@ and see for yourself.
> > You can say what you will about some of those ports, but what it
> > /does/ show, is commitment, and long term commitment to boot!
> > I grow weary of the circular discussions surrounding portmaster. So
> > this is what I'd like to propose. It's maintenance is a bigger job for
> > anyone whom is not it's original author, for anyone that did not
> > grow it from 

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 22:05:05 + Grzegorz Junka  wrote

> On 05/10/2017 21:53, Chris H wrote:
> > On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote
> >
> >>> On 5 Oct, 2017, at 10:28, Steve Kargl 
> >>> wrote:
> >>> On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> > On 5 Oct, 2017, at 9:25, Steve Kargl 
> > wrote: Which brings me back to my i686 laptop with limited resources.
> > If portmgr makes it impractical/impossible to easily install ports
> > without a sledge hammer, then testing possible future patches to
> > libm will simply skip i686 class hardware.
>  I'm not clear what role you think portmgr has in this. Portmgr
>  merely brings new features to the ports tree. Portmgr itself is
>  responsible for no build tool other than "make install".
> 
>  I don't know how many times I need to keep saying this, but
>  portmgr is not killing off portmaster. There is simply nobody
>  developing portmaster anymore, and that is not portmgr's
>  responsibility. There ARE people developing poudriere, and
>  that is why poudriere continues to work with new ports tree features.
> 
> >>> I suppose it's a matter of semantics.  If the Makefiles and *.mk
> >>> files under /usr/ports are altered to allow subpackages and
> >>> flavours to enhance pkg and poudriere, which will break portmaster
> >>> further, then yes portmgr has made a decision to endorse a sledge
> >>> hammer over simple tools.
> >>>
> >>> Mere users of the ports collection are not privy to discussions
> >>> on a portmgr alias/mailinglist.  A quick scan of the members of
> >>> portmgr and contributors to poudriere show at least 4 common
> >>> members.  There are 8 people listed under portmgr.  When decisions
> >>> were being made on the introduction of subpackages/flavours into
> >>> the ports collection, did the 4 common members recluse themselves
> >>> from any formal or informal vote?  If no, then there is certainly
> >>> a conflict-of-interest in what is best for the ports collection
> >>> versus what is best for poudriere.
> >>>
> >>> Yes, portmaster is currently unmaintained.  Doug Barton left
> >>> FreeBSD developement because he was continually brow beaten
> >>> whenever he pointed out what he felt were (serious) flaws in
> >>> FreeBSD and in the ports collection.
> >> Not quite. It works in the other direction. Ports isn't designed for
> >> poudriere. Poudriere is designed for ports. 100% of the flavours
> >> development is happening in public. Anybody who wishes to work on
> >> portmaster can participate in the process too.
> >>
> >> I think you have a misperception of the relationship between portmgr and
> >> poudriere. The coming flavours would break poudriere too, except there are
> >> people actively developing it.
> >>
> >> You seem to be fully convinced in a conspiracy to destroy portmaster, and
> >> I don't get the impression that I'm going to change your mind. All I can
> >> tell you is that impending portmaster breakage is NOT by design, and is
> >> only happening because portmaster isn't actively developed anymore. If
> >> you'd like to believe in secret poudriere cabals and anti-portmaster
> >> conspiracies, that's up to you.
> >>
> >> # Adam
> > While I have no intention to speak on Steve's behalf. I /would/ like
> > to speak in his humble defense;
> > over year ago, I attempted to become maintainer for
> > ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
> > it's value, and 2) it had been scorned for some time, and there were
> > /many/ discussions to have it removed. At the time I attempted the
> > request, it had not "officially" had a maintainer, and there was
> > serious talk as to /really/ having it removed from the ports tree.
> > bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
> > mailing list for portmaster /will/ show /many/ heated discussions
> > regarding it's removal -- this thread included. In any event, after
> > a few inquiries regarding taking maintainer for the port. My request
> > was ultimately declined. I was deemed unqualified. That judgement was
> > unfounded. :(
> > Granted, maintenance of portmaster is no small feat -- it's an
> > enormous scriptbal. But now some months later, I am maintainer for
> > ~120 ports! perform a search for portmaster@ and see for yourself.
> > You can say what you will about some of those ports, but what it
> > /does/ show, is commitment, and long term commitment to boot!
> > I grow weary of the circular discussions surrounding portmaster. So
> > this is what I'd like to propose. It's maintenance is a bigger job for
> > anyone whom is not it's original author, for anyone that did not
> > grow it from scratch, and become so intimately familiar with it. So
> > perhaps a better solution might be for me to attempt again ask to
> > become maintainer. But this 

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:08, Baho Utot wrote:



On 10/05/17 16:27, Grzegorz Junka wrote:


On 05/10/2017 19:54, Baho Utot wrote:



On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD 
leaders 2 years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any 
change and make the most noise influence you. There will always be 
edge case user who think their needs out weight what is best for 
the group.


So what you are really saying is Go to hell old farts we don't need 
you here.  We are not going to listen to you as you are too old to 
know anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.


But do those old farts have anything interesting to say or they are 
just making noise? What's the alternative to the proposed direction?


GrzegorzJ


Everyone should be heard.  who knows if the direction would be the same?

You won't hear from this old fart as every time I have had a question 
or input on direction All I got was grief.


The last time was about pkgng.  As someone that moved from 
LFS/building my own distribution to FreeBSD, and adding a package 
manager and tools for LFS.  I think I may have learned something in 
that process.  SO what did you folks do, Well I was just bitch slapped 
down.  So much for user input.  Hell pkgng can not even merge 
configurations file in /etc when is that going to be fixed. Also the 
packaging of base is just a cluster fuck, there are no other words for 
that non sense.  When the base packaging was started it was told that 
by 11.0 it would be done and here it is at 11.1 and it still a cluster 
fuck.  Now you want to add flavors,  good grief you can not even 
finish the other projects that were started how will this flavors 
thing work out?


Anyway it looks like I will be moving to OpenBSD or just go back to 
rolling my own as I have more free time to pursue building systems 
that work for me.  FreeBSD just doesn't look like it will be a fit for 
me in the future.




What you are saying (or what I am reading) is that the direction isn't 
wrong, but rather that there is too much technical debt being left 
behind. That's not the same thing. Merging configurations in /etc or 
packaging of base are fixable regardless if there are flavours or not. 
So, again, what's the alternative to the proposed direction? If you are 
saying that there could have been a better alternative if the technical 
debt hasn't been left behind then I still don't get it how it would have 
made a difference.

GrzegorzJ


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Russell L. Carter]

On 10/05/17 14:53, Chris H wrote:

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote


On 5 Oct, 2017, at 10:28, Steve Kargl 
wrote:
On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:

On 5 Oct, 2017, at 9:25, Steve Kargl 
wrote: Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to
libm will simply skip i686 class hardware.


I'm not clear what role you think portmgr has in this. Portmgr
merely brings new features to the ports tree. Portmgr itself is
responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but
portmgr is not killing off portmaster. There is simply nobody
developing portmaster anymore, and that is not portmgr's
responsibility. There ARE people developing poudriere, and
that is why poudriere continues to work with new ports tree features.



I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.


Not quite. It works in the other direction. Ports isn't designed for
poudriere. Poudriere is designed for ports. 100% of the flavours development
is happening in public. Anybody who wishes to work on portmaster can
participate in the process too.

I think you have a misperception of the relationship between portmgr and
poudriere. The coming flavours would break poudriere too, except there are
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and I
don't get the impression that I'm going to change your mind. All I can tell
you is that impending portmaster breakage is NOT by design, and is only
happening because portmaster isn't actively developed anymore. If you'd like
to believe in secret poudriere cabals and anti-portmaster conspiracies,
that's up to you.

# Adam

While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for
no other reason, for my own sanity. But better; that it can/will be
more promptly addressed. IOW problems that arise, can more easily
be addressed when a group of individuals are involved with it's
maintenance.

Seem a reasonable request? If [found] so, I'll solicit for qualified
individuals to work with me on it in a new thread.

Thanks for your time, and consideration


Why don't you fork portmaster, call it eg portmaster-ch, make it a
port, hack away, 

Re: portmaster, portupgrade, etc

[Adam Weinberger]

> On 5 Oct, 2017, at 15:53, Chris H  wrote:
> 
> On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote
> 
>>> On 5 Oct, 2017, at 10:28, Steve Kargl 
>>> wrote: 
>>> On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> On 5 Oct, 2017, at 9:25, Steve Kargl 
> wrote: Which brings me back to my i686 laptop with limited resources.
> If portmgr makes it impractical/impossible to easily install ports
> without a sledge hammer, then testing possible future patches to 
> libm will simply skip i686 class hardware.
 
 I'm not clear what role you think portmgr has in this. Portmgr
 merely brings new features to the ports tree. Portmgr itself is
 responsible for no build tool other than "make install".
 
 I don't know how many times I need to keep saying this, but
 portmgr is not killing off portmaster. There is simply nobody
 developing portmaster anymore, and that is not portmgr's
 responsibility. There ARE people developing poudriere, and
 that is why poudriere continues to work with new ports tree features.
 
>>> 
>>> I suppose it's a matter of semantics.  If the Makefiles and *.mk
>>> files under /usr/ports are altered to allow subpackages and
>>> flavours to enhance pkg and poudriere, which will break portmaster
>>> further, then yes portmgr has made a decision to endorse a sledge
>>> hammer over simple tools.
>>> 
>>> Mere users of the ports collection are not privy to discussions
>>> on a portmgr alias/mailinglist.  A quick scan of the members of 
>>> portmgr and contributors to poudriere show at least 4 common
>>> members.  There are 8 people listed under portmgr.  When decisions
>>> were being made on the introduction of subpackages/flavours into
>>> the ports collection, did the 4 common members recluse themselves
>>> from any formal or informal vote?  If no, then there is certainly
>>> a conflict-of-interest in what is best for the ports collection
>>> versus what is best for poudriere.
>>> 
>>> Yes, portmaster is currently unmaintained.  Doug Barton left
>>> FreeBSD developement because he was continually brow beaten
>>> whenever he pointed out what he felt were (serious) flaws in
>>> FreeBSD and in the ports collection.
>> 
>> Not quite. It works in the other direction. Ports isn't designed for
>> poudriere. Poudriere is designed for ports. 100% of the flavours development
>> is happening in public. Anybody who wishes to work on portmaster can
>> participate in the process too. 
>> 
>> I think you have a misperception of the relationship between portmgr and
>> poudriere. The coming flavours would break poudriere too, except there are
>> people actively developing it. 
>> 
>> You seem to be fully convinced in a conspiracy to destroy portmaster, and I
>> don't get the impression that I'm going to change your mind. All I can tell
>> you is that impending portmaster breakage is NOT by design, and is only
>> happening because portmaster isn't actively developed anymore. If you'd like
>> to believe in secret poudriere cabals and anti-portmaster conspiracies,
>> that's up to you. 
>> 
>> # Adam
> While I have no intention to speak on Steve's behalf. I /would/ like
> to speak in his humble defense;
> over year ago, I attempted to become maintainer for
> ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
> it's value, and 2) it had been scorned for some time, and there were
> /many/ discussions to have it removed. At the time I attempted the
> request, it had not "officially" had a maintainer, and there was
> serious talk as to /really/ having it removed from the ports tree.
> bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
> mailing list for portmaster /will/ show /many/ heated discussions
> regarding it's removal -- this thread included. In any event, after
> a few inquiries regarding taking maintainer for the port. My request
> was ultimately declined. I was deemed unqualified. That judgement was
> unfounded. :(

I remember that. I have to admit, I was pretty shocked by it as well.

> Granted, maintenance of portmaster is no small feat -- it's an
> enormous scriptbal. But now some months later, I am maintainer for
> ~120 ports! perform a search for portmaster@ and see for yourself.
> You can say what you will about some of those ports, but what it
> /does/ show, is commitment, and long term commitment to boot!
> I grow weary of the circular discussions surrounding portmaster. So
> this is what I'd like to propose. It's maintenance is a bigger job for
> anyone whom is not it's original author, for anyone that did not
> grow it from scratch, and become so intimately familiar with it. So
> perhaps a better solution might be for me to attempt again ask to
> become maintainer. But this time, make it a group effort -- if for
> no other reason, for my own sanity. But better; that it 

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 20:27:19 + Grzegorz Junka  wrote

> On 05/10/2017 19:54, Baho Utot wrote:
> >
> >
> > On 10/04/17 16:39, Ernie Luzar wrote:
> >
> >> Here's my take on that.
> >>
> >> The future direction has already been decided by the FreeBSD leaders 
> >> 2 years ago with their development of a better pkg system.
> >>
> >
> > [putolin]
> >
> >> Don't let the few old school die hearts who are afraid of any change 
> >> and make the most noise influence you. There will always be edge case 
> >> user who think their needs out weight what is best for the group.
> >
> > So what you are really saying is Go to hell old farts we don't need 
> > you here.  We are not going to listen to you as you are too old to 
> > know anything.  You are old and stupid.
> >
> > It is looking like I will need to move away from FreeBSD if that is 
> > really what is being accomplished here.
> 
> But do those old farts have anything interesting to say or they are just 
> making noise? What's the alternative to the proposed direction?\

This is an *extremely* difficult question to answer, and these discussions
come up all too often. The short answer is; shut up and code! -- Meaning;
since FreeBSD exists, and grows because of those whom are willing to
produce code to accomplish it. Those who put their code, where their
mouth is, will be the deciding vote. :)
I'm not always loving it. But it is, what it is, and it's hard to argue
with it. No? :)

--Chris

P.S. I'm one of the "Greybeards" ;)

> 
> GrzegorzJ
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Baho Utot]

On 10/05/17 16:27, Grzegorz Junka wrote:


On 05/10/2017 19:54, Baho Utot wrote:



On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 
2 years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any change 
and make the most noise influence you. There will always be edge case 
user who think their needs out weight what is best for the group.


So what you are really saying is Go to hell old farts we don't need 
you here.  We are not going to listen to you as you are too old to 
know anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.


But do those old farts have anything interesting to say or they are just 
making noise? What's the alternative to the proposed direction?


GrzegorzJ


Everyone should be heard.  who knows if the direction would be the same?

You won't hear from this old fart as every time I have had a question or 
input on direction All I got was grief.


The last time was about pkgng.  As someone that moved from LFS/building 
my own distribution to FreeBSD, and adding a package manager and tools 
for LFS.  I think I may have learned something in that process.  SO what 
did you folks do, Well I was just bitch slapped down.  So much for user 
input.  Hell pkgng can not even merge configurations file in /etc when 
is that going to be fixed.  Also the packaging of base is just a cluster 
fuck, there are no other words for that non sense.  When the base 
packaging was started it was told that by 11.0 it would be done and here 
it is at 11.1 and it still a cluster fuck.  Now you want to add flavors, 
 good grief you can not even finish the other projects that were 
started how will this flavors thing work out?


Anyway it looks like I will be moving to OpenBSD or just go back to 
rolling my own as I have more free time to pursue building systems that 
work for me.  FreeBSD just doesn't look like it will be a fit for me in 
the future.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 21:53, Chris H wrote:

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote


On 5 Oct, 2017, at 10:28, Steve Kargl 
wrote:
On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:

On 5 Oct, 2017, at 9:25, Steve Kargl 
wrote: Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to
libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr
merely brings new features to the ports tree. Portmgr itself is
responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but
portmgr is not killing off portmaster. There is simply nobody
developing portmaster anymore, and that is not portmgr's
responsibility. There ARE people developing poudriere, and
that is why poudriere continues to work with new ports tree features.


I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.

Not quite. It works in the other direction. Ports isn't designed for
poudriere. Poudriere is designed for ports. 100% of the flavours development
is happening in public. Anybody who wishes to work on portmaster can
participate in the process too.

I think you have a misperception of the relationship between portmgr and
poudriere. The coming flavours would break poudriere too, except there are
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and I
don't get the impression that I'm going to change your mind. All I can tell
you is that impending portmaster breakage is NOT by design, and is only
happening because portmaster isn't actively developed anymore. If you'd like
to believe in secret poudriere cabals and anti-portmaster conspiracies,
that's up to you.

# Adam

While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for


What does it mean in practical terms? A list of signatories under your 
candidature and a recommendation letter? Endorsements sent to a 
particular email?


I don't quite understand why would anybody want to decline a request to 
maintain a port that is unmaintained otherwise? Are they expecting 
better candidatures? I would understand if they had 10 proposals to 
maintain the same port, but not if there is just one? But I am not good 
at politics so 

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 15:54:32 -0400 Baho Utot  wrote

> On 10/04/17 16:39, Ernie Luzar wrote:
> 
> > Here's my take on that.
> > 
> > The future direction has already been decided by the FreeBSD leaders 2 
> > years ago with their development of a better pkg system.
> > 
> 
> [putolin]
> 
> > Don't let the few old school die hearts who are afraid of any change and 
> > make the most noise influence you. There will always be edge case user 
> > who think their needs out weight what is best for the group.
> 
> So what you are really saying is Go to hell old farts we don't need you 
> here.  We are not going to listen to you as you are too old to know 
> anything.  You are old and stupid.
> 
> It is looking like I will need to move away from FreeBSD if that is 
> really what is being accomplished here.

Honestly. That statement irritated me, as well. Who is Ernie to act
as the FreeBSD spokesman, and for what's best for FreeBSD as a whole. :(

> 
> > 
> > Remember that your updated book will become a bible for many years and 
> > many readers. Don't include items that are now on the edge of being 
> > replaced.
> > 
> > Another candidate is JAILs  IE: the old way of jail definition was in 
> > rc.conf the new way being jail.conf. The jail.conf method was 
> > introduction was at RELEASE 9.0 and here its 11.1 and still the old 
> > school users fight to retain both ways. Hoping that with 12.0, support 
> > for jail definition in rc.conf will be totally removed.
> > 
> > One last though. The problem with the Freebsd handbook is that it reads 
> > like a list of reminder notes. The reader is expected to already have a 
> > well defined understanding of the subject being read about. The past 2 
> > years a great amount of effort has gone into bring the handbook up to 
> > date with the current status of the operating system. But it is a very 
> > far cry from a teaching aid.
> > 
> > Please take the time to rework the original "Absolute FreeBSD" content 
> > into something that is usable as a teaching book. You must assume that 
> > the only thing the reader knows about Freebsd is how to spell the word 
> > Freebsd and build the content from there.
> > 
> > Good luck.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > freebsd-ports@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Chris H]

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote

> > On 5 Oct, 2017, at 10:28, Steve Kargl 
> > wrote: 
> > On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> >>> On 5 Oct, 2017, at 9:25, Steve Kargl 
> >>> wrote: Which brings me back to my i686 laptop with limited resources.
> >>> If portmgr makes it impractical/impossible to easily install ports
> >>> without a sledge hammer, then testing possible future patches to 
> >>> libm will simply skip i686 class hardware.
> >> 
> >> I'm not clear what role you think portmgr has in this. Portmgr
> >> merely brings new features to the ports tree. Portmgr itself is
> >> responsible for no build tool other than "make install".
> >> 
> >> I don't know how many times I need to keep saying this, but
> >> portmgr is not killing off portmaster. There is simply nobody
> >> developing portmaster anymore, and that is not portmgr's
> >> responsibility. There ARE people developing poudriere, and
> >> that is why poudriere continues to work with new ports tree features.
> >> 
> > 
> > I suppose it's a matter of semantics.  If the Makefiles and *.mk
> > files under /usr/ports are altered to allow subpackages and
> > flavours to enhance pkg and poudriere, which will break portmaster
> > further, then yes portmgr has made a decision to endorse a sledge
> > hammer over simple tools.
> > 
> > Mere users of the ports collection are not privy to discussions
> > on a portmgr alias/mailinglist.  A quick scan of the members of 
> > portmgr and contributors to poudriere show at least 4 common
> > members.  There are 8 people listed under portmgr.  When decisions
> > were being made on the introduction of subpackages/flavours into
> > the ports collection, did the 4 common members recluse themselves
> > from any formal or informal vote?  If no, then there is certainly
> > a conflict-of-interest in what is best for the ports collection
> > versus what is best for poudriere.
> > 
> > Yes, portmaster is currently unmaintained.  Doug Barton left
> > FreeBSD developement because he was continually brow beaten
> > whenever he pointed out what he felt were (serious) flaws in
> > FreeBSD and in the ports collection.
> 
> Not quite. It works in the other direction. Ports isn't designed for
> poudriere. Poudriere is designed for ports. 100% of the flavours development
> is happening in public. Anybody who wishes to work on portmaster can
> participate in the process too. 
>
> I think you have a misperception of the relationship between portmgr and
> poudriere. The coming flavours would break poudriere too, except there are
> people actively developing it. 
>
> You seem to be fully convinced in a conspiracy to destroy portmaster, and I
> don't get the impression that I'm going to change your mind. All I can tell
> you is that impending portmaster breakage is NOT by design, and is only
> happening because portmaster isn't actively developed anymore. If you'd like
> to believe in secret poudriere cabals and anti-portmaster conspiracies,
> that's up to you. 
>
> # Adam
While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for
no other reason, for my own sanity. But better; that it can/will be
more promptly addressed. IOW problems that arise, can more easily
be addressed when a group of individuals are involved with it's
maintenance.

Seem a reasonable request? If [found] so, I'll solicit for qualified

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 19:54, Baho Utot wrote:



On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 
2 years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any change 
and make the most noise influence you. There will always be edge case 
user who think their needs out weight what is best for the group.


So what you are really saying is Go to hell old farts we don't need 
you here.  We are not going to listen to you as you are too old to 
know anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.


But do those old farts have anything interesting to say or they are just 
making noise? What's the alternative to the proposed direction?


GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 18:41, Steve Kargl wrote:

On Thu, Oct 05, 2017 at 10:52:51AM -0600, Adam Weinberger wrote:

(courtesy long-line wrap)


You seem to be fully convinced in a conspiracy to destroy
portmaster, and I don't get the impression that I'm going
to change your mind. All I can tell you is that impending
portmaster breakage is NOT by design, and is only happening
because portmaster isn't actively developed anymore. If
you'd like to believe in secret poudriere cabals and
anti-portmaster conspiracies, that's up to you.

Nope. No conspiracy theory here.  But, the above is a good
method to deflect attention and blame.

I simply find it ironic/comical that someone dreamt up
flavours/subpackage for the ports collections with the
knowledge that this will break all tools used to manage
ports, and portmgr which is charged with

Discusses how that the way that the Ports Collection is
implemented affects the above policies, and, in particular,
such concepts as changes that require regression tests and
sweeping changes.

(see https://www.freebsd.org/portmgr/) seems to have endorsed
a "sweeping change" with this outcome.

Then that someone managed to convince developers of a single
ports management tool to implement support for flavours/subpackaged.
So, portmgr now is going ahead with a "sweeping change" at the expense
of all other ports management tool.  I have simply pointed out, portmgr
and contributors to that single ports manange tool have a significant
overlap.  Nope.  No conspiracy.  Just the truth.

So, Adam, if the poudriere developers had stated that poudriere
would not support flavors/subpackages would portmgr still wedge
the necessary infrastructure into the Makefiles and *.mk files?



I don't understand this argument. Are flavours / subpackages good / 
desirable or they are not good / undesirable? As far as I know they 
enable features that otherwise wouldn't be possible. So surely not the 
later. So if the former, could they have been designed in a way that 
doesn't break existing build tools? Maybe yes, but if that was the case 
then surely someone would have proposed such a design? Or maybe even 
implemented it. Maybe at an additional cost of non-trivial changes 
somewhere else. Maybe updating the build tools was the easier option. In 
the end those are just build tools and no one should expect them to 
never change. But if that was the case, how would they go about updating 
ports to support new features? Of course, they would discuss with the 
maintainers of those tools, (why wouldn't they ?), if the change is 
feasible to implement in the tools and would take less effort than the 
mentioned change somewhere else instead. How many maintainers they would 
need to contact? I know of 4 - portmaster, portupgrade, synth and 
poudriere. Am I missing something? Oh, yes, the mighty make. But it will 
be mass-updated so no need to look for anyone. So, who should they 
contact to discuss the support for ports/subpackages in portmaster, 
portupgrade and synth? Should they hold off until a maintainer is found? 
Should they pay for updating these tools from their pocket (using their 
time)?


GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Baho Utot]

On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 2 
years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any change and 
make the most noise influence you. There will always be edge case user 
who think their needs out weight what is best for the group.


So what you are really saying is Go to hell old farts we don't need you 
here.  We are not going to listen to you as you are too old to know 
anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.




Remember that your updated book will become a bible for many years and 
many readers. Don't include items that are now on the edge of being 
replaced.


Another candidate is JAILs  IE: the old way of jail definition was in 
rc.conf the new way being jail.conf. The jail.conf method was 
introduction was at RELEASE 9.0 and here its 11.1 and still the old 
school users fight to retain both ways. Hoping that with 12.0, support 
for jail definition in rc.conf will be totally removed.


One last though. The problem with the Freebsd handbook is that it reads 
like a list of reminder notes. The reader is expected to already have a 
well defined understanding of the subject being read about. The past 2 
years a great amount of effort has gone into bring the handbook up to 
date with the current status of the operating system. But it is a very 
far cry from a teaching aid.


Please take the time to rework the original "Absolute FreeBSD" content 
into something that is usable as a teaching book. You must assume that 
the only thing the reader knows about Freebsd is how to spell the word 
Freebsd and build the content from there.


Good luck.







___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Thu, Oct 05, 2017 at 10:52:51AM -0600, Adam Weinberger wrote:

(courtesy long-line wrap)

> You seem to be fully convinced in a conspiracy to destroy
> portmaster, and I don't get the impression that I'm going
> to change your mind. All I can tell you is that impending
> portmaster breakage is NOT by design, and is only happening
> because portmaster isn't actively developed anymore. If
> you'd like to believe in secret poudriere cabals and
> anti-portmaster conspiracies, that's up to you.

Nope. No conspiracy theory here.  But, the above is a good
method to deflect attention and blame.

I simply find it ironic/comical that someone dreamt up
flavours/subpackage for the ports collections with the 
knowledge that this will break all tools used to manage
ports, and portmgr which is charged with

   Discusses how that the way that the Ports Collection is
   implemented affects the above policies, and, in particular,
   such concepts as changes that require regression tests and
   sweeping changes.

(see https://www.freebsd.org/portmgr/) seems to have endorsed
a "sweeping change" with this outcome.  

Then that someone managed to convince developers of a single
ports management tool to implement support for flavours/subpackaged.
So, portmgr now is going ahead with a "sweeping change" at the expense
of all other ports management tool.  I have simply pointed out, portmgr
and contributors to that single ports manange tool have a significant
overlap.  Nope.  No conspiracy.  Just the truth.

So, Adam, if the poudriere developers had stated that poudriere
would not support flavors/subpackages would portmgr still wedge
the necessary infrastructure into the Makefiles and *.mk files?

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Adam Weinberger]

> On 5 Oct, 2017, at 10:28, Steve Kargl  
> wrote:
> 
> On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
>>> On 5 Oct, 2017, at 9:25, Steve Kargl  
>>> wrote:
>>> Which brings me back to my i686 laptop with limited resources.
>>> If portmgr makes it impractical/impossible to easily install ports
>>> without a sledge hammer, then testing possible future patches to 
>>> libm will simply skip i686 class hardware.
>> 
>> I'm not clear what role you think portmgr has in this. Portmgr
>> merely brings new features to the ports tree. Portmgr itself is
>> responsible for no build tool other than "make install".
>> 
>> I don't know how many times I need to keep saying this, but
>> portmgr is not killing off portmaster. There is simply nobody
>> developing portmaster anymore, and that is not portmgr's
>> responsibility. There ARE people developing poudriere, and
>> that is why poudriere continues to work with new ports tree features.
>> 
> 
> I suppose it's a matter of semantics.  If the Makefiles and *.mk
> files under /usr/ports are altered to allow subpackages and
> flavours to enhance pkg and poudriere, which will break portmaster
> further, then yes portmgr has made a decision to endorse a sledge
> hammer over simple tools.
> 
> Mere users of the ports collection are not privy to discussions
> on a portmgr alias/mailinglist.  A quick scan of the members of 
> portmgr and contributors to poudriere show at least 4 common
> members.  There are 8 people listed under portmgr.  When decisions
> were being made on the introduction of subpackages/flavours into
> the ports collection, did the 4 common members recluse themselves
> from any formal or informal vote?  If no, then there is certainly
> a conflict-of-interest in what is best for the ports collection
> versus what is best for poudriere.
> 
> Yes, portmaster is currently unmaintained.  Doug Barton left
> FreeBSD developement because he was continually brow beaten
> whenever he pointed out what he felt were (serious) flaws in
> FreeBSD and in the ports collection.

Not quite. It works in the other direction. Ports isn't designed for poudriere. 
Poudriere is designed for ports. 100% of the flavours development is happening 
in public. Anybody who wishes to work on portmaster can participate in the 
process too.

I think you have a misperception of the relationship between portmgr and 
poudriere. The coming flavours would break poudriere too, except there are 
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and I 
don't get the impression that I'm going to change your mind. All I can tell you 
is that impending portmaster breakage is NOT by design, and is only happening 
because portmaster isn't actively developed anymore. If you'd like to believe 
in secret poudriere cabals and anti-portmaster conspiracies, that's up to you.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:
> > On 5 Oct, 2017, at 9:25, Steve Kargl  
> > wrote:
> > Which brings me back to my i686 laptop with limited resources.
> > If portmgr makes it impractical/impossible to easily install ports
> > without a sledge hammer, then testing possible future patches to 
> > libm will simply skip i686 class hardware.
> 
> I'm not clear what role you think portmgr has in this. Portmgr
> merely brings new features to the ports tree. Portmgr itself is
> responsible for no build tool other than "make install".
> 
> I don't know how many times I need to keep saying this, but
> portmgr is not killing off portmaster. There is simply nobody
> developing portmaster anymore, and that is not portmgr's
> responsibility. There ARE people developing poudriere, and
> that is why poudriere continues to work with new ports tree features.
> 

I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of 
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Konstantin Belousov]

On Thu, Oct 05, 2017 at 08:25:20AM -0700, Steve Kargl wrote:
> On Thu, Oct 05, 2017 at 05:59:41PM +0300, Konstantin Belousov wrote:
> > On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
> > > On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> > > > On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > > > > The system in question is my last i686 laptop, which I 
> > > > > > use for libm development and testing.  Once I cannot use
> > > > > > that laptop (whether hardware failure or inability to 
> > > > > > update the installed ports), I'll stop worrying about a
> > > > > > functional libm on 32-bit hardware.
> > > > > 
> > > > > As an aside, this sort of thing could be done in an i386 VM or maybe 
> > > > > an
> > > > > i386 jail on amd64 hardware.
> > > > 
> > > > You do not need even a jail for this. Base cc -m32 works on amd64 for
> > > > long time, and 32bit binaries can be executed from host environment,
> > > > assuming all third-party libs are provided somewhere in the 32bit
> > > > variant.
> > > > 
> > > > The environment with regard to the hardware configuration should be
> > > > identical to modern i386-arch machine with SSE2.  Incompatibilities are
> > > > considered as bugs and are usually fixed fast when reported.
> > > 
> > > Does this required WITH_LIB32=yes in src.conf?
> > Yes, but this is the default.
> > 
> > > 
> > > More concerning is that the FPU on i686 is set-up in npx to
> > > use 53-bit precision instead of 64-bit.  See x86/fpu.h where
> > > there is a large comment and the settings
> > > 
> > > #define __INITIAL_FPUCW__   0x037F
> > > #define __INITIAL_FPUCW_I386__  0x127F
> > > #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> > > 
> > > Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
> > > and i387?
> > It is not cc -m32.
> > 
> > Kernel sets up x87 FPU differently for 64 and 32bit processes. See
> > ia32_setregs() where pcb is adjusted for 32bit, and r189423.
> 
> Yes, I know the kernel sets up npx on i686.  If one is testing libm
> changes or new code for libm, then cc -m32 will be insufficient in
> testing the behavior one might get from i387 in 53-bit mode as 
> oppose to 64-bit.  This is the reason the macro LD80C exists in
> math_private.h.
Again, if there is any bug in setting FPU environment for 32bit process,
i.e. an inconsistency between native i386 kernel and compat32 on amd64,
explain it or better, provide the test case.  It will be fixed quickly.

Currently I am not aware of any.

> 
> Which brings me back to my i686 laptop with limited resources.
> If portmgr makes it impractical/impossible to easily install ports
> without a sledge hammer, then testing possible future patches to 
> libm will simply skip i686 class hardware.
> 
> -- 
> Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Adam Weinberger]

> On 5 Oct, 2017, at 9:25, Steve Kargl  
> wrote:
> 
> On Thu, Oct 05, 2017 at 05:59:41PM +0300, Konstantin Belousov wrote:
>> On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
>>> On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
 On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
>> The system in question is my last i686 laptop, which I 
>> use for libm development and testing.  Once I cannot use
>> that laptop (whether hardware failure or inability to 
>> update the installed ports), I'll stop worrying about a
>> functional libm on 32-bit hardware.
> 
> As an aside, this sort of thing could be done in an i386 VM or maybe an
> i386 jail on amd64 hardware.
 
 You do not need even a jail for this. Base cc -m32 works on amd64 for
 long time, and 32bit binaries can be executed from host environment,
 assuming all third-party libs are provided somewhere in the 32bit
 variant.
 
 The environment with regard to the hardware configuration should be
 identical to modern i386-arch machine with SSE2.  Incompatibilities are
 considered as bugs and are usually fixed fast when reported.
>>> 
>>> Does this required WITH_LIB32=yes in src.conf?
>> Yes, but this is the default.
>> 
>>> 
>>> More concerning is that the FPU on i686 is set-up in npx to
>>> use 53-bit precision instead of 64-bit.  See x86/fpu.h where
>>> there is a large comment and the settings
>>> 
>>> #define __INITIAL_FPUCW__   0x037F
>>> #define __INITIAL_FPUCW_I386__  0x127F
>>> #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
>>> 
>>> Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
>>> and i387?
>> It is not cc -m32.
>> 
>> Kernel sets up x87 FPU differently for 64 and 32bit processes. See
>> ia32_setregs() where pcb is adjusted for 32bit, and r189423.
> 
> Yes, I know the kernel sets up npx on i686.  If one is testing libm
> changes or new code for libm, then cc -m32 will be insufficient in
> testing the behavior one might get from i387 in 53-bit mode as 
> oppose to 64-bit.  This is the reason the macro LD80C exists in
> math_private.h.
> 
> Which brings me back to my i686 laptop with limited resources.
> If portmgr makes it impractical/impossible to easily install ports
> without a sledge hammer, then testing possible future patches to 
> libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr merely brings 
new features to the ports tree. Portmgr itself is responsible for no build tool 
other than "make install".

I don't know how many times I need to keep saying this, but portmgr is not 
killing off portmaster. There is simply nobody developing portmaster anymore, 
and that is not portmgr's responsibility. There ARE people developing 
poudriere, and that is why poudriere continues to work with new ports tree 
features.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Thu, Oct 05, 2017 at 05:59:41PM +0300, Konstantin Belousov wrote:
> On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
> > On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> > > On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > > > The system in question is my last i686 laptop, which I 
> > > > > use for libm development and testing.  Once I cannot use
> > > > > that laptop (whether hardware failure or inability to 
> > > > > update the installed ports), I'll stop worrying about a
> > > > > functional libm on 32-bit hardware.
> > > > 
> > > > As an aside, this sort of thing could be done in an i386 VM or maybe an
> > > > i386 jail on amd64 hardware.
> > > 
> > > You do not need even a jail for this. Base cc -m32 works on amd64 for
> > > long time, and 32bit binaries can be executed from host environment,
> > > assuming all third-party libs are provided somewhere in the 32bit
> > > variant.
> > > 
> > > The environment with regard to the hardware configuration should be
> > > identical to modern i386-arch machine with SSE2.  Incompatibilities are
> > > considered as bugs and are usually fixed fast when reported.
> > 
> > Does this required WITH_LIB32=yes in src.conf?
> Yes, but this is the default.
> 
> > 
> > More concerning is that the FPU on i686 is set-up in npx to
> > use 53-bit precision instead of 64-bit.  See x86/fpu.h where
> > there is a large comment and the settings
> > 
> > #define __INITIAL_FPUCW__   0x037F
> > #define __INITIAL_FPUCW_I386__  0x127F
> > #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> > 
> > Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
> > and i387?
> It is not cc -m32.
> 
> Kernel sets up x87 FPU differently for 64 and 32bit processes. See
> ia32_setregs() where pcb is adjusted for 32bit, and r189423.

Yes, I know the kernel sets up npx on i686.  If one is testing libm
changes or new code for libm, then cc -m32 will be insufficient in
testing the behavior one might get from i387 in 53-bit mode as 
oppose to 64-bit.  This is the reason the macro LD80C exists in
math_private.h.

Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to 
libm will simply skip i686 class hardware.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Konstantin Belousov]

On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
> On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> > On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > > The system in question is my last i686 laptop, which I 
> > > > use for libm development and testing.  Once I cannot use
> > > > that laptop (whether hardware failure or inability to 
> > > > update the installed ports), I'll stop worrying about a
> > > > functional libm on 32-bit hardware.
> > > 
> > > As an aside, this sort of thing could be done in an i386 VM or maybe an
> > > i386 jail on amd64 hardware.
> > 
> > You do not need even a jail for this. Base cc -m32 works on amd64 for
> > long time, and 32bit binaries can be executed from host environment,
> > assuming all third-party libs are provided somewhere in the 32bit
> > variant.
> > 
> > The environment with regard to the hardware configuration should be
> > identical to modern i386-arch machine with SSE2.  Incompatibilities are
> > considered as bugs and are usually fixed fast when reported.
> 
> Does this required WITH_LIB32=yes in src.conf?
Yes, but this is the default.

> 
> More concerning is that the FPU on i686 is set-up in npx to
> use 53-bit precision instead of 64-bit.  See x86/fpu.h where
> there is a large comment and the settings
> 
> #define __INITIAL_FPUCW__   0x037F
> #define __INITIAL_FPUCW_I386__  0x127F
> #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> 
> Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
> and i387?
It is not cc -m32.

Kernel sets up x87 FPU differently for 64 and 32bit processes. See
ia32_setregs() where pcb is adjusted for 32bit, and r189423.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
> On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > > The system in question is my last i686 laptop, which I 
> > > use for libm development and testing.  Once I cannot use
> > > that laptop (whether hardware failure or inability to 
> > > update the installed ports), I'll stop worrying about a
> > > functional libm on 32-bit hardware.
> > 
> > As an aside, this sort of thing could be done in an i386 VM or maybe an
> > i386 jail on amd64 hardware.
> 
> You do not need even a jail for this. Base cc -m32 works on amd64 for
> long time, and 32bit binaries can be executed from host environment,
> assuming all third-party libs are provided somewhere in the 32bit
> variant.
> 
> The environment with regard to the hardware configuration should be
> identical to modern i386-arch machine with SSE2.  Incompatibilities are
> considered as bugs and are usually fixed fast when reported.

Does this required WITH_LIB32=yes in src.conf?

More concerning is that the FPU on i686 is set-up in npx to
use 53-bit precision instead of 64-bit.  See x86/fpu.h where
there is a large comment and the settings

#define __INITIAL_FPUCW__   0x037F
#define __INITIAL_FPUCW_I386__  0x127F
#define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__

Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
and i387?

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mike Clarke]

On Wednesday 04 Oct 2017 16:39:25 Ernie Luzar wrote:
> Here's my take on that.
> 
> The future direction has already been decided by the FreeBSD leaders 2 
> years ago with their development of a better pkg system.
> 
> The package system with flavors will cover 90% of the user community
> needs. The remaining user's requirements are edge cases. Tools like 
> portmaster and portupgrad and even the native ports system usage on 
> personal machines will fad away. The ports system will mature into the 
> development system in the path to get things into the package system.

Well I suppose I fall into the remaining 10% of the user community so here's my 
two cents 
worth.

I rely almost entirely on installing binary packages but I need to run php71 
for compatibility 
with a website I maintain. I also need phpMyAdmin but need to build this from 
ports because 
the currently available package is built against php56. Using poudriere for 
this one task would 
be equivalent to using a steamroller to crack a peanut. Building phpMyAdmin 
from ports is no 
great problem for me and perhaps future development of pkg might avoid the need 
to build 
my own version but I'd hope that documented methods will continue to exist for 
users with 
this type of need.

-- 
Mike Clarke
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Konstantin Belousov]

On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
> > The system in question is my last i686 laptop, which I 
> > use for libm development and testing.  Once I cannot use
> > that laptop (whether hardware failure or inability to 
> > update the installed ports), I'll stop worrying about a
> > functional libm on 32-bit hardware.
> 
> As an aside, this sort of thing could be done in an i386 VM or maybe an
> i386 jail on amd64 hardware.

You do not need even a jail for this. Base cc -m32 works on amd64 for
long time, and 32bit binaries can be executed from host environment,
assuming all third-party libs are provided somewhere in the 32bit
variant.

The environment with regard to the hardware configuration should be
identical to modern i386-arch machine with SSE2.  Incompatibilities are
considered as bugs and are usually fixed fast when reported.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Alexander Leidinger]

Quoting Adam Weinberger  (from Wed, 4 Oct 2017  
19:14:22 -0600):


Portmaster is still very much a part of the current landscape, and  
if somebody steps in to fix it (which I have every expectation will  
happen eventually), it will continue being a usable alternative.


It would help to have a list of broken items in portmaster.
I'm aware of the broken package support (can't create packages / can't  
use existing packages).


Flavour/subpackages support? It would be nice to have a description  
how it is supposed to work (how to identify the flavour in the package  
name / port, how to detect subpackages in the package name / port, how  
to create a subpackage from a port, how to create a specific flavour  
from the port).


What else?

Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpGkR4wMA6Et.pgp
Description: Digitale PGP-Signatur

Re: portmaster, portupgrade, etc

[Franco Fichtner]

> On 5. Oct 2017, at 9:47 AM, Eugene Grosbein  wrote:
> 
> On 05.10.2017 08:14, Adam Weinberger wrote:
> 
>> Poudriere wants to be everything to everybody
> 
> First poudriere will have to learn how to run without noticeable overhead
> compared to "just build from ports" before it could became "everything to 
> everybody"
> and it needs to became part of base system for that purpose.

For OPNsense we broke down the poudriere approach into a simple
equivalent that is capable of building inside a jail, resume
after a faulty build and wrap everything into a ready to use
(pkg-repo creation and signing) archive that can be moved to
a remote location and unpacked to be used as an online package
repo, but it would also work on a singular system.

https://github.com/opnsense/tools/blob/master/build/ports.sh

In case someone feels the need to know this before starting from
scratch trying to build something simple.  It does not support
clever multi-threading, but then again it would work as anyone
would use the ports tree manually and runs well in a headless
mode setting via cron for nightly rebuild fun.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Eugene Grosbein]

On 05.10.2017 08:14, Adam Weinberger wrote:

> Poudriere wants to be everything to everybody

First poudriere will have to learn how to run without noticeable overhead
compared to "just build from ports" before it could became "everything to 
everybody"
and it needs to became part of base system for that purpose.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Eugene Grosbein]

On 05.10.2017 04:22, Steve Kargl wrote:

> I did not state that the "environment is constrained by poudriere".
> The environment is contrained due to resource limits.  If you
> only have 1 Gb of memory and 5-10 GB diskspace, then using poudriere
> with zfs and jails is a nonstarter.  Yes, I'm aware that zfs is not
> required.  Can't find info on whether jails can be avoided.  Having
> say lang/llvm40 installed in /usr/local and in a jail would consumes
> 2.6 GB.  That's 1 port! 

In fact, a jail is not needed too. Just perform installworld
to a /path, then mount -t devfs devfs /path/dev; mount -t nullfs /usr/ports 
/path/usr/ports
and you are ready to build with chroot /path make -C /usr/ports/net/quagga 
package".
Perhaps, you'll also need to setup /path/etc/resolv.conf unless you have 
caching DNS
server running locally, so fetch(1) could download distfiles.



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Eugene Grosbein]

> Why compile ports directly on a box that is so hardware constrained that it
> will take multiple hours to do, when a "pkg update; pkg upgrade" takes only
> a few minutes?

I tried really hard to run small virtual machine (1GB RAM, 25G disk) hosted at 
Hetzner
without using ports and can say it's impossible. Pre-built packages from 
official repo
are just too heavy and bloat the system with unneeded run-time dependencies
not to mention impossibility to apply hot-fix in form of a patch.
And running own repository is just not an option for such system.

portupgrade (or analog) plus ZFS compressed svn-updates ports tree is lightest 
option in practice:

zfs_load="YES"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="8M"
vfs.zfs.prefetch_disable="1"
vfs.zfs.vdev.trim_on_init="0"
vfs.zfs.compressed_arc_enabled="1"

You can even run UFS-based system with /usr/ports mounted occasionally
and zfs.ko/opensolaris.ko unloaded when not needed to free memory.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[blubee blubeeme]

Interesting thread, I've learned more about FreeBSD build here than almost
anywhere else.

Thanks OP for the email.

On Thu, Oct 5, 2017, 09:14 Adam Weinberger  wrote:

> > On 4 Oct, 2017, at 10:16, Michael W. Lucas 
> wrote:
> >
> > Hi,
> >
> > I'm doing tech edits on the new edition of "Absolute FreeBSD," and
> > stumbled into what's apparently a delicate topic.
> >
> > Some of my reviewers are happy I included portmaster in the book.
> >
> > Some reviewers beg me not to include it.
> >
> > Unfortunately, people will be reading af3e and considering it
> > definitive for the next several years. So I have to get a feel for
> > where things are going. :-/
> >
> > I've read a couple threads on portmaster's current problems/growing
> > pains and its looming difficulty with forthcoming flavors.
> >
> > I've been a happy portmaster user for many years now. All things being
> > equal, if its future is still being debated I'm inclined to keep it in
> > the book.
> >
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
> >
> > Truly, I'm not looking to start a flame war here. I only want a bit of
> > guidance on The Future...
> >
> > ==ml
>
> Hi Michael,
>
> Poudriere is indeed intended to be the canonical port building and
> management tool. It is what essentially the entire ports committer team
> uses, it's what the clusters build with, and it is where support for new
> features land first.
>
> Portmaster is a tried-and-tested tool for automating port builds.
> Poudriere wants to be everything to everybody, but portmaster is as simple
> to use as possible. The current issue is that portmaster is no longer
> actively developed. Major new features are about to land in the ports tree,
> and portmaster will either not support them, or will break entirely.
>
> The official message is that everybody for whom Poudriere's workflow works
> should migrate to Poudriere to avoid the impending breakage.
>
> Portmaster is still very much a part of the current landscape, and if
> somebody steps in to fix it (which I have every expectation will happen
> eventually), it will continue being a usable alternative.
>
> # Adam
>
>
> --
> Adam Weinberger
> ad...@adamw.org
> https://www.adamw.org
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Adam Weinberger]

> On 4 Oct, 2017, at 10:16, Michael W. Lucas  wrote:
> 
> Hi,
> 
> I'm doing tech edits on the new edition of "Absolute FreeBSD," and
> stumbled into what's apparently a delicate topic.
> 
> Some of my reviewers are happy I included portmaster in the book.
> 
> Some reviewers beg me not to include it.
> 
> Unfortunately, people will be reading af3e and considering it
> definitive for the next several years. So I have to get a feel for
> where things are going. :-/
> 
> I've read a couple threads on portmaster's current problems/growing
> pains and its looming difficulty with forthcoming flavors.
> 
> I've been a happy portmaster user for many years now. All things being
> equal, if its future is still being debated I'm inclined to keep it in
> the book.
> 
> Poudriere really needs its own small book. Yes, you can do simple
> poudriere installs, but once you start covering it properly the docs
> quickly expand. My notes alone are longer than my af3e chapter
> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> 2018).
> 
> Truly, I'm not looking to start a flame war here. I only want a bit of
> guidance on The Future...
> 
> ==ml

Hi Michael,

Poudriere is indeed intended to be the canonical port building and management 
tool. It is what essentially the entire ports committer team uses, it's what 
the clusters build with, and it is where support for new features land first.

Portmaster is a tried-and-tested tool for automating port builds. Poudriere 
wants to be everything to everybody, but portmaster is as simple to use as 
possible. The current issue is that portmaster is no longer actively developed. 
Major new features are about to land in the ports tree, and portmaster will 
either not support them, or will break entirely.

The official message is that everybody for whom Poudriere's workflow works 
should migrate to Poudriere to avoid the impending breakage.

Portmaster is still very much a part of the current landscape, and if somebody 
steps in to fix it (which I have every expectation will happen eventually), it 
will continue being a usable alternative.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Don Lewis]

On  4 Oct, Steve Kargl wrote:
> On Wed, Oct 04, 2017 at 05:29:14PM -0500, Mark Linimon wrote:
>> Please understand that I'm not trying to be obstinate,
>> I'm trying to understand.
> 
> Me too.
> 
>> Background: years ago I managed the cluster of i386 blades
>> that we used in package building.  933MHz and 512MB IIRC.
>> So I am familiar with constraint problems.
> 
> The system in question is my last i686 laptop, which I 
> use for libm development and testing.  Once I cannot use
> that laptop (whether hardware failure or inability to 
> update the installed ports), I'll stop worrying about a
> functional libm on 32-bit hardware.

As an aside, this sort of thing could be done in an i386 VM or maybe an
i386 jail on amd64 hardware.

>> On Wed, Oct 04, 2017 at 02:22:25PM -0700, Steve Kargl wrote:
>> > Can't find info on whether jails can be avoided.
>> 
>> I have not checked the code but IIRC, no.  I thought jails
>> had low memory overhead, though.
> 
> That's good, but memory overhead isn't the problem with a
> jail.  It's the diskspace used to duplicate everything
> already available in /bin:/usr/bin:/usr/local/bin:... and
> storage to hold the packages as things get built.
> 
>> > If you only have 1 Gb of memory and 5-10 GB diskspace,
>> > then using poudriere with zfs and jails is a nonstarter.
>> 
>> For point of comparison, with those constraints, I do not
>> understand how modern llvms can build at all.
>> 
>> What happens if you use the manual approach on this same
>> system?  e.g.
>> 
>>   cd /usr/ports/devel/llvm40
>>   mkdir -p /usr/ports/packages
>>   make && make package
>>   pkg install /usr/ports/packages/llvm.txz
> 
> I normally do 
> 
> portmaster -Byd devel/llvm40
> 
> and wait a day for the build to complete.  I have 
> /usr/ports/distfiles symlinked to a USB2 /mnt/distfiles
> (40 MB/s max throughput).  I may also need to set
> DISABLE_MAKE_JOBS="YES", but can't remember offhand.
> 
>> 
>> Do you still run out of resources?
>> 
> 
> No. I have 4 GB of swap space, which is well used during the
> build.  The system is actually quite usable as portmaster
> runs.  I also build libreoffice and octave on the system.

That must be fun ...

At some point you'll run into the problem that even one copy of the
ports that you want to install and just one copy of all their
dependencies will no longer fit and then you have to start tossing
out stuff that you would really like to install and use.  I'm pretty
sure that I no longer have enough room to build all the stuff on my
laptop that I currently have installed (openoffice warns that it needs
11GB of free space). In that case, if you move the package building off
to another machine, you don't even have to install many of the build
dependencies on the target machine.  For instance, I have a list of 214
ports that I want to install on my desktop machine. When I feed that
into poudriere, it builds something on the order of 1900 ports.  When I
do the pkg install on my desktop machine with the same list, only 1431
packages get installed.

>> In that case, there's not much that can be done.  The
>> compilers, the office suites, and certain math packages
>> are huge beasts.  However you try to build them won't
>> matter.
>> 
>> I would think having a copy of the llvm workfiles in a jail
>> is going to be equivalent to having them in /tmp?
>> 
>> I must be missing something.
> 
> portmaster satisfies its dependencies from already installed
> ports in /usr/local.  There isn't a clean room full of pkg'd
> dependencies sitting in some jail while llvm40 builds.

The llvm40 problem should be helped a lot by subpackages.  If you
install a package that was built by llvm40 and uses its shared
libraries, hopefully pkg will install a subpackage that contains the
llvm40 .so files and not all of the compiler bits.  You would only get
those if you manually installed llvm40 so that you could use the
compiler bits.  In that case, poudriere would only cause two copies of
the .so files to be installed and the compiler bits would only be
installed on the machine (in the build jail) when poudriere was using a
port that needed the llvm40 compiler.  The same will be true of other
things that are installed because of LIB_DEPENDS.  Things like the
include files, docs, and static libraries won't get automatically
installed just because a port is a dependency of something else.  They
would only need to be manually installed if you want to build something
manually outside of the ports framework.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Wed, Oct 04, 2017 at 05:29:14PM -0500, Mark Linimon wrote:
> Please understand that I'm not trying to be obstinate,
> I'm trying to understand.

Me too.

> Background: years ago I managed the cluster of i386 blades
> that we used in package building.  933MHz and 512MB IIRC.
> So I am familiar with constraint problems.

The system in question is my last i686 laptop, which I 
use for libm development and testing.  Once I cannot use
that laptop (whether hardware failure or inability to 
update the installed ports), I'll stop worrying about a
functional libm on 32-bit hardware.

> On Wed, Oct 04, 2017 at 02:22:25PM -0700, Steve Kargl wrote:
> > Can't find info on whether jails can be avoided.
> 
> I have not checked the code but IIRC, no.  I thought jails
> had low memory overhead, though.

That's good, but memory overhead isn't the problem with a
jail.  It's the diskspace used to duplicate everything
already available in /bin:/usr/bin:/usr/local/bin:... and
storage to hold the packages as things get built.

> > If you only have 1 Gb of memory and 5-10 GB diskspace,
> > then using poudriere with zfs and jails is a nonstarter.
> 
> For point of comparison, with those constraints, I do not
> understand how modern llvms can build at all.
> 
> What happens if you use the manual approach on this same
> system?  e.g.
> 
>   cd /usr/ports/devel/llvm40
>   mkdir -p /usr/ports/packages
>   make && make package
>   pkg install /usr/ports/packages/llvm.txz

I normally do 

portmaster -Byd devel/llvm40

and wait a day for the build to complete.  I have 
/usr/ports/distfiles symlinked to a USB2 /mnt/distfiles
(40 MB/s max throughput).  I may also need to set
DISABLE_MAKE_JOBS="YES", but can't remember offhand.

> 
> Do you still run out of resources?
> 

No. I have 4 GB of swap space, which is well used during the
build.  The system is actually quite usable as portmaster
runs.  I also build libreoffice and octave on the system.

> In that case, there's not much that can be done.  The
> compilers, the office suites, and certain math packages
> are huge beasts.  However you try to build them won't
> matter.
> 
> I would think having a copy of the llvm workfiles in a jail
> is going to be equivalent to having them in /tmp?
> 
> I must be missing something.

portmaster satisfies its dependencies from already installed
ports in /usr/local.  There isn't a clean room full of pkg'd
dependencies sitting in some jail while llvm40 builds.

So, I think the issue comes down to "portmaster allows an
in-place update of installed ports" vs "poudriere builds
a repository of packages from which one can then do an
update"

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mark Linimon]

On Wed, Oct 04, 2017 at 09:56:53PM +, Grzegorz Junka wrote:
> portmaster/portupgrade  trade off doing less work with
> less resources in an attempt to produce less rigorously
> correct result

That was what I thought I said :-) or at least was trying
to say.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mark Linimon]

Please understand that I'm not trying to be obstinate,
I'm trying to understand.

Background: years ago I managed the cluster of i386 blades
that we used in package building.  933MHz and 512MB IIRC.
So I am familiar with constraint problems.

On Wed, Oct 04, 2017 at 02:22:25PM -0700, Steve Kargl wrote:
> Can't find info on whether jails can be avoided.

I have not checked the code but IIRC, no.  I thought jails
had low memory overhead, though.

> If you only have 1 Gb of memory and 5-10 GB diskspace,
> then using poudriere with zfs and jails is a nonstarter.

For point of comparison, with those constraints, I do not
understand how modern llvms can build at all.

What happens if you use the manual approach on this same
system?  e.g.

  cd /usr/ports/devel/llvm40
  mkdir -p /usr/ports/packages
  make && make package
  pkg install /usr/ports/packages/llvm.txz

Do you still run out of resources?

In that case, there's not much that can be done.  The
compilers, the office suites, and certain math packages
are huge beasts.  However you try to build them won't
matter.

I would think having a copy of the llvm workfiles in a jail
is going to be equivalent to having them in /tmp?

I must be missing something.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 21:00, Mark Linimon wrote:

On Wed, Oct 04, 2017 at 08:56:00PM +, Grzegorz Junka wrote:

Maybe I am just too ambitious or maybe poudriere is more
idiot-proof?

My possibly incorrect understanding is that poudriere
trades off doing a lot more work in an attempt to produce
more rigorously correct results.



I think it's the other way around. Poudriere does as much as a 
standalone build server would have to do, but it does it in a jail, so 
the main system isn't affected and can be used to non-build related work 
in the meantime. It's portmaster/portupgrade that trade off doing less 
work with less resources in an attempt to produce less rigorously 
correct result (and often no result at all, or even an additional work 
needed to restore the build server to a working condition).

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 21:22, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 08:30:49PM +, Grzegorz Junka wrote:

On 04/10/2017 19:40, Steve Kargl wrote:

Ahem, yeah, so I'm not allowed to request a short description
on how to use poudiere in a resource constrained environment?


The environment isn't constrained by poudriere but by the ports you want
to compile. When compiling libreoffice or chromium or firefox I don't
think there is anything else that can be done than setting poudriere to
run no more than 1 job at a time. Poudriere itself doesn't take any
additional resources, it's just a dedicated jail and a bunch of scripts.


I did not state that the "environment is constrained by poudriere".
The environment is contrained due to resource limits.  If you
only have 1 Gb of memory and 5-10 GB diskspace, then using poudriere
with zfs and jails is a nonstarter.  Yes, I'm aware that zfs is not
required.  Can't find info on whether jails can be avoided.  Having
say lang/llvm40 installed in /usr/local and in a jail would consumes
2.6 GB.  That's 1 port!



Would temporarily spinning up an EC2 instance on AWS be an option? It's 
priced per hour so shouldn't cost much to compile required packages? On 
the other hand, a desktop with 4GB of RAM and 250GB HDD costs $50-100.


I sometimes think if setting up a build system where someone would be 
able to build ports with their own customized options could become 
popular...


GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Wed, Oct 04, 2017 at 08:30:49PM +, Grzegorz Junka wrote:
> 
> On 04/10/2017 19:40, Steve Kargl wrote:
> > Ahem, yeah, so I'm not allowed to request a short description
> > on how to use poudiere in a resource constrained environment?
> >
> 
> The environment isn't constrained by poudriere but by the ports you want 
> to compile. When compiling libreoffice or chromium or firefox I don't 
> think there is anything else that can be done than setting poudriere to 
> run no more than 1 job at a time. Poudriere itself doesn't take any 
> additional resources, it's just a dedicated jail and a bunch of scripts.
> 

I did not state that the "environment is constrained by poudriere".
The environment is contrained due to resource limits.  If you
only have 1 Gb of memory and 5-10 GB diskspace, then using poudriere
with zfs and jails is a nonstarter.  Yes, I'm aware that zfs is not
required.  Can't find info on whether jails can be avoided.  Having
say lang/llvm40 installed in /usr/local and in a jail would consumes
2.6 GB.  That's 1 port! 

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Freddie Cash]

On Wed, Oct 4, 2017 at 1:56 PM, Grzegorz Junka  wrote:

>
> On 04/10/2017 20:43, Mark Linimon wrote:
>
>> On Wed, Oct 04, 2017 at 08:13:16PM +, Grzegorz Junka wrote:
>>
>>> I was trying
>>> to compile with the system that was being updated at the
>>> same time - this can't possibly work (or can it?).
>>>
>> It works somewhere between "quite often" to "nearly all
>> the time".  It can vary depending on the complexity of
>>
>
> Well, that's not my experience. For me it worked occasionally at best. A
> few times the system became so broken that many applications couldn't be
> opened any more and I had to spend hours to restore it to some kind of
> usability. Even with poudriere I still manage to break the ports quite
> often by setting various options not to their recommended values - see
> defects I have been raising on https://www.freebsd.org/suppor
> t/bugreports.html But at least I am not able to install them until they
> are fixed.
>
> Maybe I am just too ambitious or maybe poudriere is more idiot-proof? I
> guess portmaster or portupgrade may work fine if one uses the default
> options, but in that case, hey, why bother? Just use the compiled packages!
> If you try to change some ports to non-default options, and something
> doesn't compile, portmaster/portupgrade will leave the system in half-baked
> state. And then only heavens can help...


​The nice thing about poudriere is that it doesn't affect the running
system.  The act of creating the package repo is completely separate from
the act of installing packages.  The two steps can be done on a single
system, or on separate systems.

During the creation of the package repo via poudriere, nothing on the
client system is affected; nothing is installed, nothing is uninstalled.
One can continue to use the system, which is great for desktops and
critical servers alike.

If there's an issue compiling a port in the middle of a long dependency
chain in poudriere, the process stops and you work to fix it.  Nothing you
do at this point affects any of the client(s).  If you can't get it fixed,
you don't have to worry about rolling back versions on the client(s) to get
things back to a working state.

Only once you have everything compiled and packaged up do you worry about
the client system(s).  And there, the pkg system takes over and handles
everything.  It's pretty much a "everything works or nothing gets
installed" process at that time (with very few corner cases that break
things).

It's not bulletproof, but it's a lot safer than compiling things on the
live system where some compiler bits are picked up from the ports build
tree, while other bits are picked up from the live filesystem, while some
things are auto-detected based on other installed ports, while some things
are skipped for the same reason, etc.

Will there be situations where you want to compile directly on the client?
Maybe.  Will there be many people that need that against all other
options?  Not really.

the ports you have installed, what state the tree is in,
>> how much the ports you use are often used by others, and
>> subtle differences in changes to port dependencies.
>>
>> This is complex enough to be indistinguishable from "phase
>> of the moon."
>>
>> In this case I really wish I were joking.
>>
>
​I used to love compiling everything on my home systems and work systems.
Then KDE upgrades kept leaving me with a broken system due to enabling some
esoteric OPTIONS that I thought I needed and portmaster would fail in the
middle of the umpteen-level-deep dependency chain.  I could usually get
things back to a working, upgraded state, but that usually left me without
a working GUI for 2-4 days.  The introduction of pkg has alleviated me of​
that need.  :)  I don't even have /usr/ports installed on my home or work
systems anymore.

After ending up with a broken server at work for the same reason I switched
those to using pkg only.  I played with poudriere back in the early days
and it was easy to work with.  But I found myself setting fewer and fewer
custom OPTIONS so the need for it diminished with time.  Debated playing
with it at work to get a custom OpenSSH package (for NONE encryption), but
I found other ways to do the same.

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mark Linimon]

On Wed, Oct 04, 2017 at 08:56:00PM +, Grzegorz Junka wrote:
> Maybe I am just too ambitious or maybe poudriere is more
> idiot-proof?

My possibly incorrect understanding is that poudriere
trades off doing a lot more work in an attempt to produce
more rigorously correct results.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mark Linimon]

On Wed, Oct 04, 2017 at 04:39:25PM -0400, Ernie Luzar wrote:
> even the native ports system usage on personal machines
> wwill fade away.

I have seen this claim many times by users but AFAIR that
was never a goal.  The feeling was that _most_ users would
migrate to using packages, once using packages had been made
much easier and more robust than the previous packaging
technology.  (Disclaimer: I was much more familiar with the
internals of the old pkg-* tools and the bad state that they
had gotten into.)

> The past 2 years a great
> amount of effort has gone into bring the handbook up to
> date with the current status of the operating system. But
> it is a very far cry from a teaching aid.

I have some proposed patches for the ports section that
need to be dusted off and committed.  But I think your
critism is valid -- it works as a reference better than as
a tutorial.  The latter is not fixable in the near-term
(simply due to volunteer cycles).

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 20:43, Mark Linimon wrote:

On Wed, Oct 04, 2017 at 08:13:16PM +, Grzegorz Junka wrote:

I was trying
to compile with the system that was being updated at the
same time - this can't possibly work (or can it?).

It works somewhere between "quite often" to "nearly all
the time".  It can vary depending on the complexity of


Well, that's not my experience. For me it worked occasionally at best. A 
few times the system became so broken that many applications couldn't be 
opened any more and I had to spend hours to restore it to some kind of 
usability. Even with poudriere I still manage to break the ports quite 
often by setting various options not to their recommended values - see 
defects I have been raising on 
https://www.freebsd.org/support/bugreports.html But at least I am not 
able to install them until they are fixed.


Maybe I am just too ambitious or maybe poudriere is more idiot-proof? I 
guess portmaster or portupgrade may work fine if one uses the default 
options, but in that case, hey, why bother? Just use the compiled 
packages! If you try to change some ports to non-default options, and 
something doesn't compile, portmaster/portupgrade will leave the system 
in half-baked state. And then only heavens can help...



the ports you have installed, what state the tree is in,
how much the ports you use are often used by others, and
subtle differences in changes to port dependencies.

This is complex enough to be indistinguishable from "phase
of the moon."

In this case I really wish I were joking.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Mark Linimon]

On Wed, Oct 04, 2017 at 08:13:16PM +, Grzegorz Junka wrote:
> I was trying
> to compile with the system that was being updated at the
> same time - this can't possibly work (or can it?).

It works somewhere between "quite often" to "nearly all
the time".  It can vary depending on the complexity of
the ports you have installed, what state the tree is in,
how much the ports you use are often used by others, and
subtle differences in changes to port dependencies.

This is complex enough to be indistinguishable from "phase
of the moon."

In this case I really wish I were joking.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Ernie Luzar]

Michael W. Lucas wrote:

Hi,

I'm doing tech edits on the new edition of "Absolute FreeBSD," and
stumbled into what's apparently a delicate topic.

Some of my reviewers are happy I included portmaster in the book.

Some reviewers beg me not to include it.

Unfortunately, people will be reading af3e and considering it
definitive for the next several years. So I have to get a feel for
where things are going. :-/

I've read a couple threads on portmaster's current problems/growing
pains and its looming difficulty with forthcoming flavors.

I've been a happy portmaster user for many years now. All things being
equal, if its future is still being debated I'm inclined to keep it in
the book.

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Truly, I'm not looking to start a flame war here. I only want a bit of
guidance on The Future...

==ml



Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 2 
years ago with their development of a better pkg system.


The package system with flavors will cover 90% of the user community
needs. The remaining user's requirements are edge cases. Tools like 
portmaster and portupgrad and even the native ports system usage on 
personal machines will fad away. The ports system will mature into the 
development system in the path to get things into the package system.


You adding details on these port system tools will only give the reader 
the impression that they are still popular and being actively supported 
thus working against the intended direction Freebsd package system is 
headed. Making it even harder to get users to move forward.


Don't let the few old school die hearts who are afraid of any change and 
make the most noise influence you. There will always be edge case user 
who think their needs out weight what is best for the group.


Remember that your updated book will become a bible for many years and 
many readers. Don't include items that are now on the edge of being 
replaced.


Another candidate is JAILs  IE: the old way of jail definition was in 
rc.conf the new way being jail.conf. The jail.conf method was 
introduction was at RELEASE 9.0 and here its 11.1 and still the old 
school users fight to retain both ways. Hoping that with 12.0, support 
for jail definition in rc.conf will be totally removed.


One last though. The problem with the Freebsd handbook is that it reads 
like a list of reminder notes. The reader is expected to already have a 
well defined understanding of the subject being read about. The past 2 
years a great amount of effort has gone into bring the handbook up to 
date with the current status of the operating system. But it is a very 
far cry from a teaching aid.


Please take the time to rework the original "Absolute FreeBSD" content 
into something that is usable as a teaching book. You must assume that 
the only thing the reader knows about Freebsd is how to spell the word 
Freebsd and build the content from there.


Good luck.







___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 19:40, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 02:57:08PM -0400, George Mitchell wrote:

On 10/04/17 14:14, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:

On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:


On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Please include a discussion on how to use poudriere on
a system with limited resouces [...]

​Pretty sure the standard response will be along the lines of:​ [...]

Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
to simply build ports with custom options.  [...]

While I agree with you, allow me to insert a gentle reminder that the
OP was asking only about whether to include portmaster in his book.
I suggest that he should. -- George

Ahem, yeah, so I'm not allowed to request a short description
on how to use poudiere in a resource constrained environment?



The environment isn't constrained by poudriere but by the ports you want 
to compile. When compiling libreoffice or chromium or firefox I don't 
think there is anything else that can be done than setting poudriere to 
run no more than 1 job at a time. Poudriere itself doesn't take any 
additional resources, it's just a dedicated jail and a bunch of scripts.


I would rather say that the amount of resources poudriere takes to 
compile stuff is normal, the baseline. Portmaster or portupgrade make a 
compromise - unstable compilation environment for some additional memory 
to compile especially resource hungry ports.


What I am trying to say is that there isn't probably much to discuss. 
However, explaining the difference between portmaster/portupgrade and 
poudriere and how to plan computer resources for compiling various sizes 
of ports may be more useful?


GrzegorzJ
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 16:16, Michael W. Lucas wrote:

Hi,

I'm doing tech edits on the new edition of "Absolute FreeBSD," and
stumbled into what's apparently a delicate topic.

Some of my reviewers are happy I included portmaster in the book.

Some reviewers beg me not to include it.

Unfortunately, people will be reading af3e and considering it
definitive for the next several years. So I have to get a feel for
where things are going. :-/

I've read a couple threads on portmaster's current problems/growing
pains and its looming difficulty with forthcoming flavors.

I've been a happy portmaster user for many years now. All things being
equal, if its future is still being debated I'm inclined to keep it in
the book.

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Truly, I'm not looking to start a flame war here. I only want a bit of
guidance on The Future...



If describing the basic usage of poudriere takes more than 2-3 pages 
then something is wrong. The handbook has it covered in just a few 
paragraphs:

https://www.freebsd.org/doc/handbook/ports-poudriere.html

When I moved to FreeBSD I tried for months to use portmaster and 
portupgrade because that was the official way described in the handbook. 
But there were always problems. I was happy when my system was still 
usable after an upgrade, not mentioning the upgraded ports to work as 
expected.


I remember often thinking, what kind of system this FeeBSD is if even a 
simple update from sources can screw up so many things! Is anyone really 
using it, or is it some kind of niche OS, the sort of MorphOS or AROS?


I started looking on the internet how others compile it, and I 
discovered that I was doing it all wrong!!! I read that handbook chapter 
and it all made sense. I was trying to compile with the system that was 
being updated at the same time - this can't possibly work (or can it?). 
I spent one afternoon setting up poudriere and I haven't looked back 
since then.


If you wish please mention portmaster and/or portupgrade, but IN 
ADDITION to poudriere. I can't imagine a serious book on FreeBSD not 
giving at least as much space to poudriere as to the other tools.


It's great that Absolute FreeBSD is getting an update. That was an 
indispensable source of information when I was learning the FreeBSD way. 
But it became outdated quite quickly. Please make an effort to discuss 
things that are not getting outdated as quickly this time.


GrzegorzJ

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Wed, Oct 04, 2017 at 02:57:08PM -0400, George Mitchell wrote:
> On 10/04/17 14:14, Steve Kargl wrote:
> > On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:
> >> On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
> >> s...@troutmask.apl.washington.edu> wrote:
> >>
> >>> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> 
>  Poudriere really needs its own small book. Yes, you can do simple
>  poudriere installs, but once you start covering it properly the docs
>  quickly expand. My notes alone are longer than my af3e chapter
>  limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
>  2018).
> >>>
> >>> Please include a discussion on how to use poudriere on
> >>> a system with limited resouces [...]
> >> ​Pretty sure the standard response will be along the lines of:​ [...]
> > Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
> > to simply build ports with custom options.  [...]
> While I agree with you, allow me to insert a gentle reminder that the
> OP was asking only about whether to include portmaster in his book.
> I suggest that he should. -- George

Ahem, yeah, so I'm not allowed to request a short description
on how to use poudiere in a resource constrained environment?

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/04/17 14:14, Steve Kargl wrote:
> On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:
>> On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
>> s...@troutmask.apl.washington.edu> wrote:
>>
>>> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:

 Poudriere really needs its own small book. Yes, you can do simple
 poudriere installs, but once you start covering it properly the docs
 quickly expand. My notes alone are longer than my af3e chapter
 limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
 2018).
>>>
>>> Please include a discussion on how to use poudriere on
>>> a system with limited resouces [...]
>> ​Pretty sure the standard response will be along the lines of:​ [...]
> Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
> to simply build ports with custom options.  [...]
While I agree with you, allow me to insert a gentle reminder that the
OP was asking only about whether to include portmaster in his book.
I suggest that he should. -- George



signature.asc
Description: OpenPGP digital signature

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:
> On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> > >
> > > Poudriere really needs its own small book. Yes, you can do simple
> > > poudriere installs, but once you start covering it properly the docs
> > > quickly expand. My notes alone are longer than my af3e chapter
> > > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > > 2018).
> >
> > Please include a discussion on how to use poudriere on
> > a system with limited resouces (e.g., 10 GB of free
> > diskspace and less than 1 GB free memory).  I know
> > portmaster works well [1] within an environment with
> > only 4 GB free diskspace and 1 GB memory.
> >
> 
> ​Pretty sure the standard response will be along the lines of:​
> 
> By using pkg to fetch/install binary packages that were built by, and are
> hosted​ on, a separate box that does nothing but run poudriere to build the
> package repo using your custom specifications and OPTIONS, obviously.  :)
> 
> Why compile ports directly on a box that is so hardware constrained that it
> will take multiple hours to do, when a "pkg update; pkg upgrade" takes only
> a few minutes?
> 

Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
to simply build ports with custom options.  In my particular case,
this is my last i686 laptop where all of my libm contributions 
have been and continue to be tested.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Freddie Cash]

On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> >
> > Poudriere really needs its own small book. Yes, you can do simple
> > poudriere installs, but once you start covering it properly the docs
> > quickly expand. My notes alone are longer than my af3e chapter
> > limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> > 2018).
>
> Please include a discussion on how to use poudriere on
> a system with limited resouces (e.g., 10 GB of free
> diskspace and less than 1 GB free memory).  I know
> portmaster works well [1] within an environment with
> only 4 GB free diskspace and 1 GB memory.
>

​Pretty sure the standard response will be along the lines of:​

By using pkg to fetch/install binary packages that were built by, and are
hosted​ on, a separate box that does nothing but run poudriere to build the
package repo using your custom specifications and OPTIONS, obviously.  :)

Why compile ports directly on a box that is so hardware constrained that it
will take multiple hours to do, when a "pkg update; pkg upgrade" takes only
a few minutes?

​:)


-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[Steve Kargl]

On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:
> 
> Poudriere really needs its own small book. Yes, you can do simple
> poudriere installs, but once you start covering it properly the docs
> quickly expand. My notes alone are longer than my af3e chapter
> limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
> 2018).

Please include a discussion on how to use poudriere on
a system with limited resouces (e.g., 10 GB of free
diskspace and less than 1 GB free memory).  I know
portmaster works well [1] within an environment with
only 4 GB free diskspace and 1 GB memory.

[1] portmaster worked well prior to portmgr's decision
to displace simple small tools in favor of a sledge
hammer.

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: portmaster, portupgrade, etc

[George Mitchell]

On 10/04/17 12:16, Michael W. Lucas wrote:
> Hi,
> 
> I'm doing tech edits on the new edition of "Absolute FreeBSD," and
> stumbled into what's apparently a delicate topic.
> 
> Some of my reviewers are happy I included portmaster in the book.
> 
> Some reviewers beg me not to include it. [...]

It's hard to guess where things are going at the moment.  You can
count me among the happy users of portmaster; and I generally
incline toward the view that more information is better than less.
-- George



signature.asc
Description: OpenPGP digital signature

portmaster, portupgrade, etc

[Michael W. Lucas]

Hi,

I'm doing tech edits on the new edition of "Absolute FreeBSD," and
stumbled into what's apparently a delicate topic.

Some of my reviewers are happy I included portmaster in the book.

Some reviewers beg me not to include it.

Unfortunately, people will be reading af3e and considering it
definitive for the next several years. So I have to get a feel for
where things are going. :-/

I've read a couple threads on portmaster's current problems/growing
pains and its looming difficulty with forthcoming flavors.

I've been a happy portmaster user for many years now. All things being
equal, if its future is still being debated I'm inclined to keep it in
the book.

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Truly, I'm not looking to start a flame war here. I only want a bit of
guidance on The Future...

==ml

-- 
Michael W. Lucashttps://mwl.io/
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"