Re: The future of portmaster [and of ports-mgmt/synth]

[Thomas Mueller]

from Stari Karp:

> On Fri, 2017-06-02 at 06:24 -0400, Jim Ohlstein wrote:
> > On Fri, 2017-06-02 at 06:10 -0400, Stari Karp wrote:
> > > Looks like the new portmaster is coming but what is about Synth? I am
> > > the user of Synth and I like to know what the FreeBSD leaders decided, 
> > > please.

> > The "FreeBSD leaders," in their infinite wisdom, decided to can John
> > Marino. Synth development will likely go on, geared towards Dragonfly.
> > Whether it will support future FreeBSD ports enhancements is anyone's
> > guess. Whether gcc6-aux will ever be fixed for 12-CURRENT and 64 bit
> > inodes is also anyone's guess.

> > Sadly, it is/
> > was the best option for users looking to migrate to a "modern" tool for
> > whom poudriere was too much.

> I did install Dragonfly too and for my needs is very good. I am buying
> a new ssd drive and I will installed os from scratch. And I knew what
> happened with John Marino.

One problem I had with DragonFlyBSD was that I couldn't mount/read a NetBSD or 
FreeBSD partition, and FreeBSD and NetBSD couldn't mount/read a DragonFly 
partition.

That was on the DragonFly boot image written to USB stick, last version was 
somewhere before 4.4.

Latest experience (4.4.x) was that DragonFly installation boot image, written 
to USB stick, hung on boot.

I checked ports-mgmt/synth/Makefile for DPorts on github.com and see 

MAINTAINER= ericturgeon@gmail.com

but for pkgsrc-synth/pkgtools/synth in (NetBSD) pkgsrc,

MAINTAINER= dr...@marino.st
HOMEPAGE=   https://github.com/jrmarino/synth

I was not behind the scenes to judge who was right and who was wrong in the 
John Marino debacle.

It seems nobody in NetBSD, except John Marino, uses pkg or synth with pkgsrc, 
so if I try and need help, there would be no community to help.

64-bit inodes are not the only snag in 12-CURRENT.  Remember pkgbase, 
originally planned for 11.0-RELEASE?

I'll have to see what I can do with 11-STABLE and let 12-CURRENT wait on hold.

Tom

___
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: The future of portmaster [and of ports-mgmt/synth]

[Dewayne Geraghty]

Your use case is very similar to others that manage servers, particularly
on behalf of others.  We also rebuilt nightly , if any vulnerabilities were
discovered we'd test and push to clients' servers.
 :)
Cheers.
-- 
*Disclaimer:* *As implied by email protocols, the information in this
message is not confidential. Any intermediary or recipient may inspect,
modify (add), copy, forward, reply to, delete, or filter email for any
purpose unless said parties are otherwise obligated.  Nothing in this
message may be legally binding without cryptographic evidence of its
integrity and/or confidentiality.*
___
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: The future of portmaster [and of ports-mgmt/synth]

[Stari Karp]

On Fri, 2017-06-02 at 06:24 -0400, Jim Ohlstein wrote:
> On Fri, 2017-06-02 at 06:10 -0400, Stari Karp wrote:
> > Looks like the new portmaster is coming but what is about Synth? I
> > am
> > the user of Synth and I like to know what the FreeBSD leaders
> > decided,
> > please.
> > 
> 
> The "FreeBSD leaders," in their infinite wisdom, decided to can John
> Marino. Synth development will likely go on, geared towards
> Dragonfly.
> Whether it will support future FreeBSD ports enhancements is anyone's
> guess. Whether gcc6-aux will ever be fixed for 12-CURRENT and 64 bit
> inodes is also anyone's guess.
> 
> Sadly, it is/
> was the best option for users looking to migrate to a "modern" tool
> for
> whom poudriere was too much.
> 

I did install Dragonfly too and for my needs is very good. I am buying
a new ssd drive and I will installed os from scratch. And I knew what
happened with John Marino. 

___
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: The future of portmaster [and of ports-mgmt/synth]

[David Wolfskill]

On Fri, Jun 02, 2017 at 04:29:40PM +0200, Thierry Thomas wrote:
> ...
> But I have a naive question: if pkg supports flavours, and binary
> packages are built for your sets of options, is portmaster still
> relevant?
> 

Well, that depends... e.g., on one's set of requirements (and how they
are weighted).

In my own case, I believe portmaster is still relevant.  That said, I
doubt that many would have my particular set of requirements -- and that
of the few who might, very few would weight them at all similarly.

To provide a bit of context: On the systems where I use portmaster, I
also maintain private mirrors of the FreeBSD SVN repositories, which are
updated (only) overnight.  On a daily basis (on these machines -- one of
which is a designated "build machine"; the other is my laptop) I:
* Update the /usr/ports working copy.
* Update the stable/11 /usr/src working copy.
* Perform a src-based update to stable/11 (& reboot).
* While that is running, fetch the distfiles I'll be needing later
  (e.g. "portmaster -aF").
* Update all installed ports (e.g., "portmaster -ad").
* Update the "head" slice's /usr/src working copy.
* Reboot to the "head" slice.
* Perform a src-based update to head (& reboot).
* For the build machine, set the default boot slice to stable/11 & poweroff;
  for the laptop, reboot to stable/11, then use it for the rest of the day.

Please note that I am NOT recommending any of this to anyone else.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Torsten Zuehlsdorff]

On 02.06.2017 16:29, Thierry Thomas wrote:

Le jeu.  1 juin 17 à 15:45:43 +0200, Torsten Zuehlsdorff 

  écrivait :


Just as a short note: there is a complete rewrite of portmaster ongoing.
Since its a beast and everything else is very hard there is no public
evidence in case of failure. ;) Until now.


I've been using portupgrade and then portmaster for a long time. I can
understand the need for such tools when you have to build ports with
non-default options.

But I have a naive question: if pkg supports flavours, and binary
packages are built for your sets of options, is portmaster still
relevant?


No, but most portmaster user do not have the default set of options. And 
flavours do not change the options of binary packages - as far as i 
understand. The should solve problems like having multiple ports of the 
same programm but for php 5.6, 7.0 and 7.1 at the same time. Or for 
different python or ruby versions.


Greetings,
Torsten
___
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: The future of portmaster [and of ports-mgmt/synth]

[Thierry Thomas]

Le jeu.  1 juin 17 à 15:45:43 +0200, Torsten Zuehlsdorff 

 écrivait :

> Just as a short note: there is a complete rewrite of portmaster ongoing. 
> Since its a beast and everything else is very hard there is no public 
> evidence in case of failure. ;) Until now.

I've been using portupgrade and then portmaster for a long time. I can
understand the need for such tools when you have to build ports with
non-default options.

But I have a naive question: if pkg supports flavours, and binary
packages are built for your sets of options, is portmaster still
relevant?
-- 
Th. Thomas.
___
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: The future of portmaster [and of ports-mgmt/synth]

[George Mitchell]

On 06/02/17 06:24, Jim Ohlstein wrote:
> [...]
> Sadly, it is/
> was the best option for users looking to migrate to a "modern" tool for
> whom poudriere was too much.
> 

Meaning no disrespect to anyone who makes positive contributions to
the FreeBSD project, let's not forget that synth's dependence on Ada
is not to be taken lightly either.-- George



signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Mark Linimon]

On Fri, Jun 02, 2017 at 01:31:19PM +0200, Torsten Zuehlsdorff wrote:
> If someone likes synth please support it.

This.  Very much this.

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: The future of portmaster [and of ports-mgmt/synth]

[Stari Karp]

Looks like the new portmaster is coming but what is about Synth? I am
the user of Synth and I like to know what the FreeBSD leaders decided,
please.

Thank you.

SK

___
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: The future of portmaster [and of ports-mgmt/synth]

[Torsten Zuehlsdorff]

On 02.06.2017 12:24, Jim Ohlstein wrote:

On Fri, 2017-06-02 at 06:10 -0400, Stari Karp wrote:

Looks like the new portmaster is coming but what is about Synth? I am
the user of Synth and I like to know what the FreeBSD leaders
decided,
please.



The "FreeBSD leaders," in their infinite wisdom, decided to can John
Marino. Synth development will likely go on, geared towards Dragonfly.
Whether it will support future FreeBSD ports enhancements is anyone's
guess. 


While i can follow the critique i want to say: out of experience in 
various communities - online and offline: if one project is centered 
around one single person it will fail. Its just a matter of time and 
exceptions are rarely.


If someone likes synth please support it. Programming is just one single 
part needed to keep a project alive, even a programming-project. If you 
feel you are not a programmer, but for example a manager, manage to ask 
people for support, for feedback, for programming, etc.


Greetings,
Torsten
___
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: The future of portmaster [and of ports-mgmt/synth]

[Jim Ohlstein]

On Fri, 2017-06-02 at 06:10 -0400, Stari Karp wrote:
> Looks like the new portmaster is coming but what is about Synth? I am
> the user of Synth and I like to know what the FreeBSD leaders
> decided,
> please.
> 

The "FreeBSD leaders," in their infinite wisdom, decided to can John
Marino. Synth development will likely go on, geared towards Dragonfly.
Whether it will support future FreeBSD ports enhancements is anyone's
guess. Whether gcc6-aux will ever be fixed for 12-CURRENT and 64 bit
inodes is also anyone's guess.

Sadly, it is/
was the best option for users looking to migrate to a "modern" tool for
whom poudriere was too much.

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.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: The future of portmaster [and of ports-mgmt/synth]

[Torsten Zuehlsdorff]

On 01.06.2017 18:20, Matthieu Volat wrote:

On Thu, 1 Jun 2017 15:45:43 +0200
Torsten Zuehlsdorff  wrote:


[...]
Just as a short note: there is a complete rewrite of portmaster ongoing.
Since its a beast and everything else is very hard there is no public
evidence in case of failure. ;) Until now.

I'm currently try to convince all persons already got frustrated by
portmaster-programming to come together and work on it. I'm also working
at an decent automatic QA for it (and PHP and GitLab).



Hi and thanks, is there a name and a public repository for this initiative?


Currently not, but i would just name it simple like "portmaster 2". :D

The initiative is at the moment offline, besides various emails. I will 
meet with another person interested in rewrite and discuss it much more 
within the next weeks. Also there is a lot of paper with architectural 
notices, QA-requirements and ideas about what should be done and what not.


I will do a public announcement, when we start transferring it into the 
"wild". My current thought is creating a public repo on my private 
GitLab. I will use a special CI setup, but since it will need high 
permissions i need some control about what code went it.


I welcome of course every help. Beside the programming we need of course 
extensive testing and i want to improve the documentation on so many level.


Greetings,
Torsten
___
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: The future of portmaster [and of ports-mgmt/synth]

[Matthieu Volat]

On Thu, 1 Jun 2017 15:45:43 +0200
Torsten Zuehlsdorff  wrote:

> [...]
> Just as a short note: there is a complete rewrite of portmaster ongoing. 
> Since its a beast and everything else is very hard there is no public 
> evidence in case of failure. ;) Until now.
> 
> I'm currently try to convince all persons already got frustrated by 
> portmaster-programming to come together and work on it. I'm also working 
> at an decent automatic QA for it (and PHP and GitLab).
>

Hi and thanks, is there a name and a public repository for this initiative?


pgpDnNHjpXSXE.pgp
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Torsten Zuehlsdorff]

On 31.05.2017 20:31, Adam Weinberger wrote:

On 31 May, 2017, at 11:28, Per olof Ljungmark 
wrote:

On 2017-05-31 02:10, Kevin Oberman wrote:

On Tue, May 30, 2017 at 2:53 PM, Mark Linimon
> wrote: On
Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:

Hello, I have not followed this thread before but just wanted
to say that I use portmaster extensively, it works for us and I
would miss it if it went.  Are there actually plans to retire
it?

To reiterate the status: * some extensive changes to the ports
framework are coming; * these will require large changes to all
the port upgrade tools; * no one has stepped forwards to offer to
do the work for anything other than poudriere AFAIK. If no one
does the work, at the time the large changes come, the other
tools will break. People have been wanting subpackages (aka
flavors) for many years; IIUC these are parts of the changes that
are coming. Someone needs to step forwards and say "yes, I will
do the work." mcl Since portmaster is still popult and since the
only solutions that looks to be available in the near term are
pouderiere or raw make, neither terribly viable for many, I will
look into updating portmaster to deal with 'flavors'. This looks
fairly straight forward and I my have the sh capability to manage
it. (And then again, I am far from a great shell person, so I may
well be wrong.) I have looked at Doug's script and it is pretty
readable, but writing may require help. Can someone point me
where to look for documentation on flavors? I have poked around
the wiki, but to no avail. Unless there is documentation on what
needs to be done, doing it will be hopeless and waiting for the
packaging system to updated means portmaster WILL be broken for
some period of time.


Let me just say that I would really, really appriciate if we could
keep such a simple tool. Why does it suit us? Because we have a
limited number of systems, and they are all different meaning that
we custom build for almost every task. Portmaster makes very easy
to build what we need on each host. Yes, it brakes sometimes but it
is not that hard to figure out how to get around.


I want to reiterate that nobody is taking portmaster away from you.
It simply has not been actively developed for years. In all
likelihood, somebody will patch portmaster eventually. Poudriere is a
safer, more capable tool than portmaster, and it's better to migrate
when there's no immediate time pressure or breakage.

The changes are not about to drop. Portmaster is not going to stop
working tomorrow. We are bringing it up now so that you have time to
consider migrating to poudriere or synth. If your system(s) and
workflow make poudriere a viable option, we want to encourage and
help you to migrate while there's no time pressure.

Sending emails to this list about why you prefer portmaster doesn't
change the underlying problem, though: portmaster will only be
long-term viable if somebody actively develops it again.


Just as a short note: there is a complete rewrite of portmaster ongoing. 
Since its a beast and everything else is very hard there is no public 
evidence in case of failure. ;) Until now.


I'm currently try to convince all persons already got frustrated by 
portmaster-programming to come together and work on it. I'm also working 
at an decent automatic QA for it (and PHP and GitLab).


Greetings,
Torsten
___
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: The future of portmaster [and of ports-mgmt/synth]

[Mark Linimon]

On Wed, May 31, 2017 at 05:58:24PM +0100, Matthew Seaman wrote:
> Core has some proposals around planning for such changes that they will
> be talking about during the BSDCan devsummit next week.  These should
> also be published internally fairly soon afterwards for the benefit of
> people not at BSDCan.

I'll look forward to seein what the conclusions are.

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: The future of portmaster

[Thomas Mueller]

> On Wed, 2017-05-31 at 12:47 +, Gerard Seibert wrote:
> > I would just like a clarification here. For the record, synth is
> > broken
> > on FreeBSD-11 and above with amd64. Is that correct?

> My understanding was that the breakage is in gcc6-aux on 12-CURRENT
> with 64 bit inodes.

> I may be wrong...

> Jim Ohlstein

That was my understanding too, both gcc5-aux and gcc6-aux being broken on 
CURRENT with 64-bit inodes.

Now I feel like I can upgrade with 11.0-STABLE but not CURRENT.

My recent CURRENT installation seems too unstable to use as a build host.

I would rebuild 11.0-STABLE first and later use that as a host to rebuild 
CURRENT.

I would want gcc(5 or 6)-aux not only for synth but also (gcc5) to try to 
cross-compile Haiku and (gcc5 or 6) to try to cross-compile a Linux toolchain.

I would also want an updated FreeBSD system that ports would support as opposed 
to something like

FreeBSD amelia 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r294248: Mon Jan 18 
11:28:40 UTC 2016 root@amelia:/usr/obj/usr/src/sys/SANDY11NC  amd64

Regarding portmaster, when something on which a lot of other ports depend is 
upgraded, such as a major version update of png, it takes many runs of 
portmaster before everything is successfully updated.

Tom

___
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: The future of portmaster [and of ports-mgmt/synth]

[Dave Horsfall]

On Wed, 31 May 2017, Per olof Ljungmark wrote:

> Let me just say that I would really, really appriciate if we could keep 
> such a simple tool. Why does it suit us? Because we have a limited 
> number of systems, [...]

And the sytems we do have can be somewhat limited; I mean, Ada, FFS?

-- 
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: The future of portmaster [and of ports-mgmt/synth]

[Jim Trigg]

If you can give me access to a development system, I'll help.

(I only have a production server for the domains I host for a few 
not-for-profit organizations, and my home server is currently out of service 
with a bad power supply.)

Jim Trigg


On May 30, 2017 8:10:17 PM EDT, Kevin Oberman  wrote:
>On Tue, May 30, 2017 at 2:53 PM, Mark Linimon 
>wrote:
>
>> On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
>> > Hello, I have not followed this thread before but just wanted to
>say
>> > that I use portmaster extensively, it works for us and I would miss
>> > it if it went.  Are there actually plans to retire it?
>>
>> To reiterate the status:
>>
>>  * some extensive changes to the ports framework are coming;
>>  * these will require large changes to all the port upgrade tools;
>>  * no one has stepped forwards to offer to do the work for anything
>>other than poudriere AFAIK.
>>
>> If no one does the work, at the time the large changes come, the
>> other tools will break.
>>
>> People have been wanting subpackages (aka flavors) for many years;
>> IIUC these are parts of the changes that are coming.
>>
>> Someone needs to step forwards and say "yes, I will do the work."
>>
>> mcl
>
>
>Since portmaster is still popult and since the only solutions that
>looks to
>be available in the near term are pouderiere or raw make, neither
>terribly
>viable for many, I will look into updating portmaster to deal with
>'flavors'. This looks fairly straight forward and I my have the sh
>capability to manage it. (And then again, I am far from a great shell
>person, so I may well be wrong.) I have looked at Doug's script and it
>is
>pretty readable, but writing may require help.
>
>Can someone point me where to look for documentation on flavors? I have
>poked around the wiki, but to no avail. Unless there is documentation
>on
>what needs to be done, doing it will be hopeless and waiting for the
>packaging system to updated means portmaster WILL be broken for some
>period
>of time.
>--
>Kevin Oberman, Part time kid herder and retired Network Engineer
>E-mail: rkober...@gmail.com
>PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>___
>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"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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: The future of portmaster [and of ports-mgmt/synth]

[Adam Weinberger]

> On 31 May, 2017, at 11:28, Per olof Ljungmark  wrote:
> 
> 
> 
> On 2017-05-31 02:10, Kevin Oberman wrote:
>> On Tue, May 30, 2017 at 2:53 PM, Mark Linimon > > wrote:
>>On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
>>> Hello, I have not followed this thread before but just wanted to say
>>> that I use portmaster extensively, it works for us and I would miss
>>> it if it went.  Are there actually plans to retire it?
>>To reiterate the status:
>>  * some extensive changes to the ports framework are coming;
>>  * these will require large changes to all the port upgrade tools;
>>  * no one has stepped forwards to offer to do the work for anything
>>other than poudriere AFAIK.
>>If no one does the work, at the time the large changes come, the
>>other tools will break.
>>People have been wanting subpackages (aka flavors) for many years;
>>IIUC these are parts of the changes that are coming.
>>Someone needs to step forwards and say "yes, I will do the work."
>>mcl
>> Since portmaster is still popult and since the only solutions that looks to 
>> be available in the near term are pouderiere or raw make, neither terribly 
>> viable for many, I will look into updating portmaster to deal with 
>> 'flavors'. This looks fairly straight forward and I my have the sh 
>> capability to manage it. (And then again, I am far from a great shell 
>> person, so I may well be wrong.) I have looked at Doug's script and it is 
>> pretty readable, but writing may require help.
>> Can someone point me where to look for documentation on flavors? I have 
>> poked around the wiki, but to no avail. Unless there is documentation on 
>> what needs to be done, doing it will be hopeless and waiting for the 
>> packaging system to updated means portmaster WILL be broken for some period 
>> of time.
> 
> Let me just say that I would really, really appriciate if we could keep such 
> a simple tool. Why does it suit us? Because we have a limited number of 
> systems, and they are all different meaning that we custom build for almost 
> every task. Portmaster makes very easy to build what we need on each host. 
> Yes, it brakes sometimes but it is not that hard to figure out how to get 
> around.

I want to reiterate that nobody is taking portmaster away from you. It simply 
has not been actively developed for years. In all likelihood, somebody will 
patch portmaster eventually. Poudriere is a safer, more capable tool than 
portmaster, and it's better to migrate when there's no immediate time pressure 
or breakage.

The changes are not about to drop. Portmaster is not going to stop working 
tomorrow. We are bringing it up now so that you have time to consider migrating 
to poudriere or synth. If your system(s) and workflow make poudriere a viable 
option, we want to encourage and help you to migrate while there's no time 
pressure.

Sending emails to this list about why you prefer portmaster doesn't change the 
underlying problem, though: portmaster will only be long-term viable if 
somebody actively develops it again.

# 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: The future of portmaster [and of ports-mgmt/synth]

[Steve Kargl]

On Wed, May 31, 2017 at 07:28:38PM +0200, Per olof Ljungmark wrote:
> 
> On 2017-05-31 02:10, Kevin Oberman wrote:
> > On Tue, May 30, 2017 at 2:53 PM, Mark Linimon  > > wrote:
> > 
> > On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> > > Hello, I have not followed this thread before but just wanted to say
> > > that I use portmaster extensively, it works for us and I would miss
> > > it if it went.  Are there actually plans to retire it?
> > 
> > To reiterate the status:
> > 
> >   * some extensive changes to the ports framework are coming;
> >   * these will require large changes to all the port upgrade tools;
> >   * no one has stepped forwards to offer to do the work for anything
> > other than poudriere AFAIK.
> > 
> > If no one does the work, at the time the large changes come, the
> > other tools will break.
> > 
> > People have been wanting subpackages (aka flavors) for many years;
> > IIUC these are parts of the changes that are coming.
> > 
> > Someone needs to step forwards and say "yes, I will do the work."
> > 
> > mcl
> > 
> > Since portmaster is still popult and since the only solutions that looks 
> > to be available in the near term are pouderiere or raw make, neither 
> > terribly viable for many, I will look into updating portmaster to deal 
> > with 'flavors'. This looks fairly straight forward and I my have the sh 
> > capability to manage it. (And then again, I am far from a great shell 
> > person, so I may well be wrong.) I have looked at Doug's script and it 
> > is pretty readable, but writing may require help.
> > 
> > Can someone point me where to look for documentation on flavors? I have 
> > poked around the wiki, but to no avail. Unless there is documentation on 
> > what needs to be done, doing it will be hopeless and waiting for the 
> > packaging system to updated means portmaster WILL be broken for some 
> > period of time.
> 
> Let me just say that I would really, really appriciate if we could keep 
> such a simple tool. Why does it suit us? Because we have a limited 
> number of systems, and they are all different meaning that we custom 
> build for almost every task. Portmaster makes very easy to build what we 
> need on each host. Yes, it brakes sometimes but it is not that hard to 
> figure out how to get around.

+1

I have one i386 system (a laptop) with 1.5 GB of memory, at any
given time between 3-8 GB free diskspace, and a slow USB2 port.  
Poudriere and synth are simply overkill for maintaining ports 
for that laptop.

-- 
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: The future of portmaster [and of ports-mgmt/synth]

[Per olof Ljungmark]

On 2017-05-31 02:10, Kevin Oberman wrote:
On Tue, May 30, 2017 at 2:53 PM, Mark Linimon > wrote:


On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> Hello, I have not followed this thread before but just wanted to say
> that I use portmaster extensively, it works for us and I would miss
> it if it went.  Are there actually plans to retire it?

To reiterate the status:

  * some extensive changes to the ports framework are coming;
  * these will require large changes to all the port upgrade tools;
  * no one has stepped forwards to offer to do the work for anything
other than poudriere AFAIK.

If no one does the work, at the time the large changes come, the
other tools will break.

People have been wanting subpackages (aka flavors) for many years;
IIUC these are parts of the changes that are coming.

Someone needs to step forwards and say "yes, I will do the work."

mcl


Since portmaster is still popult and since the only solutions that looks 
to be available in the near term are pouderiere or raw make, neither 
terribly viable for many, I will look into updating portmaster to deal 
with 'flavors'. This looks fairly straight forward and I my have the sh 
capability to manage it. (And then again, I am far from a great shell 
person, so I may well be wrong.) I have looked at Doug's script and it 
is pretty readable, but writing may require help.


Can someone point me where to look for documentation on flavors? I have 
poked around the wiki, but to no avail. Unless there is documentation on 
what needs to be done, doing it will be hopeless and waiting for the 
packaging system to updated means portmaster WILL be broken for some 
period of time.


Let me just say that I would really, really appriciate if we could keep 
such a simple tool. Why does it suit us? Because we have a limited 
number of systems, and they are all different meaning that we custom 
build for almost every task. Portmaster makes very easy to build what we 
need on each host. Yes, it brakes sometimes but it is not that hard to 
figure out how to get around.

___
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: The future of portmaster [and of ports-mgmt/synth]

[Matthew Seaman]

On 2017/05/31 17:11, Roger Marquis wrote:
> Mark Linimon wrote:
>> * some extensive changes to the ports framework are coming;
> 
> Is there a URL (other than svnweb) where we can see a project plan for
> these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
> end-user community has reason to be worried that:
> 
>  * popular tools that were broken in the last major ports update (to
>  pkgng) will again not be considered part of the update,
> 
>  * developers and users of those tools will suffer the pain of
>  significant refactoring (again) and their Linux-advocating co-engineers
>  will be even more effective in reducing or eliminating FreeBSD in their
>  environments,
> 
>  * little discussion and few details will (again) be available before
>  the transition, and
> 
>  * it will (again) not occur exclusively on a major revision boundary.
> 
>  ** These concerns are not so much workload-related as much as they are
>  planning-related.
> 
> The lack of planning in previous ports/pkg updates was destructive and
> unnecessary.  Has anything changed?
> 
> Considering the delays in implementing base packages, pkg_audit that
> ignores base or recently deprecated ports and yet another major upgrade
> to the ports framework it should not need to be pointed out that our
> favorite OS has become far more difficult to update and maintain than
> any version of Linux.

Core has some proposals around planning for such changes that they will
be talking about during the BSDCan devsummit next week.  These should
also be published internally fairly soon afterwards for the benefit of
people not at BSDCan.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster [and of ports-mgmt/synth]

[Gerard Seibert]

On Wed, 31 May 2017 09:11:23 -0700, Roger Marquis stated:

>Mark Linimon wrote:
>> * some extensive changes to the ports framework are coming;  
>
>Is there a URL (other than svnweb) where we can see a project plan for
>these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
>end-user community has reason to be worried that:
>
>  * popular tools that were broken in the last major ports update (to
>  pkgng) will again not be considered part of the update,
>
>  * developers and users of those tools will suffer the pain of
>  significant refactoring (again) and their Linux-advocating
> co-engineers will be even more effective in reducing or eliminating
> FreeBSD in their environments,
>
>  * little discussion and few details will (again) be available before
>  the transition, and
>
>  * it will (again) not occur exclusively on a major revision boundary.
>
>  ** These concerns are not so much workload-related as much as they
> are planning-related.
>
>The lack of planning in previous ports/pkg updates was destructive and
>unnecessary.  Has anything changed?
>
>Considering the delays in implementing base packages, pkg_audit that
>ignores base or recently deprecated ports and yet another major upgrade
>to the ports framework it should not need to be pointed out that our
>favorite OS has become far more difficult to update and maintain than
>any version of Linux.
>
>> * these will require large changes to all the port upgrade tools;
>> * no one has stepped forwards to offer to do the work for anything
>>   other than poudriere AFAIK.  
>
>Perhaps this is because many of us have not heard of the extensive
>changes coming to the ports framework until now much less had the
>opportunity to contribute to discussion much less policies that should
>guide it.
>
>> If no one does the work, at the time the large changes come, the
>> other tools will break.  
>
>Bottom line, these are not just tools breaking, this is FreeBSD
>breaking.
>
>IMO,
>Roger

I would like to add that I agree with Roger, especially the “major
revision boundary” statement. Many times in the past, I have done fresh
installs of new versions of FreeBSD only to have a significant change
in that version made, forcing me to recompile ports, etcetera. I now
see that “synth” is broken on FreeBSD-12. If history repeats itself, 12
will be released, then a significant change to the ports system
initiated forcing a recompilation of the ports, etcetera to get “synth”
working again. I am sure that there are lots of other programs in the
same predicament. This is just not acceptable. Before the next release
of FreeBSD, all the base programs should be updated to their newest
versions, the “default” versions of “perl,” “python,” etcetera should
be updated as required.

-- 
Carmel
___
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: The future of portmaster [and of ports-mgmt/synth]

[Roger Marquis]

Mark Linimon wrote:

* some extensive changes to the ports framework are coming;


Is there a URL (other than svnweb) where we can see a project plan for
these changes?  As in the recent past (i.e., since 8-REL) the FreeBSD
end-user community has reason to be worried that:

 * popular tools that were broken in the last major ports update (to
 pkgng) will again not be considered part of the update,

 * developers and users of those tools will suffer the pain of
 significant refactoring (again) and their Linux-advocating co-engineers
 will be even more effective in reducing or eliminating FreeBSD in their
 environments,

 * little discussion and few details will (again) be available before
 the transition, and

 * it will (again) not occur exclusively on a major revision boundary.

 ** These concerns are not so much workload-related as much as they are
 planning-related.

The lack of planning in previous ports/pkg updates was destructive and
unnecessary.  Has anything changed?

Considering the delays in implementing base packages, pkg_audit that
ignores base or recently deprecated ports and yet another major upgrade
to the ports framework it should not need to be pointed out that our
favorite OS has become far more difficult to update and maintain than
any version of Linux.


* these will require large changes to all the port upgrade tools;
* no one has stepped forwards to offer to do the work for anything
  other than poudriere AFAIK.


Perhaps this is because many of us have not heard of the extensive
changes coming to the ports framework until now much less had the
opportunity to contribute to discussion much less policies that should
guide it.


If no one does the work, at the time the large changes come, the
other tools will break.


Bottom line, these are not just tools breaking, this is FreeBSD
breaking.

IMO,
Roger
___
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: The future of portmaster [and of ports-mgmt/synth]

[Jim Ohlstein]

On Wed, 2017-05-31 at 12:47 +, Gerard Seibert wrote:
> I would just like a clarification here. For the record, synth is
> broken
> on FreeBSD-11 and above with amd64. Is that correct?

My understanding was that the breakage is in gcc6-aux on 12-CURRENT
with 64 bit inodes.

I may be wrong...

-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.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: The future of portmaster [and of ports-mgmt/synth]

[Gerard Seibert]

I would just like a clarification here. For the record, synth is broken
on FreeBSD-11 and above with amd64. Is that correct?

-- 
Carmel
___
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: The future of portmaster

[Torsten Zuehlsdorff]

On 30.05.2017 16:00, Adam Weinberger wrote:

On 30 May, 2017, at 7:51, Anton Shterenlikht 
wrote:


when portmaster have gone away?


What? WHAT?

portmaster going away???

I hope not

Anton


The ports tree continues to evolve. Major new features are planned
and in the process of being implemented. These changes will break all
the port-building tools.

poudriere and synth are actively developed, so they will quickly
support the new changes. portmaster and portupgrade are no longer
being actively developed, so it is anticipated that they will stop
working until somebody fixes them (if at all).


While i'm the maintainer of portmaster i want to emphasize this. Keeping 
portmaster up to date is very hard. Even small changes which are double 
checked already broke something. Its a little frustrating.


BUT: there is an ongoing attempt to rewrite portmaster with an 
test-driven approach to make live much easier. But this will take time.


When having a decent hardware poudriere and synth are a good choice, you 
should definitely check out!


Greetings,
Torsten


___
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: The future of portmaster [and of ports-mgmt/synth]

[Mark Millard]

On 2017-May-30, at 1:06 PM, Mark Linimon  wrote:

> On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote:
>> Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017
>> 
>>> I really suggest that you look at synth.
> 
> synth is currently only available for x86 and unless someone steps up
> to do the work to make the Ada compilers run on the other architectures
> that is certain to remain to the case.

As I understand currently x86 and amd64 are also broken for
lang/gcc6-aux if built from a recent enough head (ino64).

True historically (x86/amd64) but briefly there was a little more,
at least for a native aarch64 context if I understand right.
(Possibly armv6 and/or armv7 too?)

My understanding is that there was a short time when aarch64 also
had Ada going via lang/gcc6-aux . But the problem of gcc's technique
of adjusting system headers so it has separate copies (supposedly to
force the headers to be language complaint) vs. FreeBSD making updates
to various headers that has gcc copied and adjusted broke the bootstrap
compiler's ability to do the bootstrap. (A compiler involved in the
bootstrap for aarch64 is actually retrieved from elsewhere as part of
the build as I remember. But it processes the headers that are as of
when the bootstrap compiler was built and made its adjustments.)

In other words: the overall mechanism (FreeBSD+gcc) is fragile and
both sides tend to think that the other side should be the one to
change how they work in order to remove the fragile status. The
two parts just do not fit well and no minor variations in how
the two operate can remove the mismatch.

I happened to do my attempted experiment that involved building
ports-mgmt/synth on aarch64 after things had broken. (I did not
try armv6/v7 but there might have been a short time when there
was context in that area that worked as well.)

aarch64 (and any others) did not last long.

Powerpc, powerpc64, mips, etc. have never attempted for Ada support
as far as know.

===
Mark Millard
markmi at dsl-only.net


___
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: The future of portmaster [and of ports-mgmt/synth]

[Kevin Oberman]

On Tue, May 30, 2017 at 2:53 PM, Mark Linimon  wrote:

> On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> > Hello, I have not followed this thread before but just wanted to say
> > that I use portmaster extensively, it works for us and I would miss
> > it if it went.  Are there actually plans to retire it?
>
> To reiterate the status:
>
>  * some extensive changes to the ports framework are coming;
>  * these will require large changes to all the port upgrade tools;
>  * no one has stepped forwards to offer to do the work for anything
>other than poudriere AFAIK.
>
> If no one does the work, at the time the large changes come, the
> other tools will break.
>
> People have been wanting subpackages (aka flavors) for many years;
> IIUC these are parts of the changes that are coming.
>
> Someone needs to step forwards and say "yes, I will do the work."
>
> mcl


Since portmaster is still popult and since the only solutions that looks to
be available in the near term are pouderiere or raw make, neither terribly
viable for many, I will look into updating portmaster to deal with
'flavors'. This looks fairly straight forward and I my have the sh
capability to manage it. (And then again, I am far from a great shell
person, so I may well be wrong.) I have looked at Doug's script and it is
pretty readable, but writing may require help.

Can someone point me where to look for documentation on flavors? I have
poked around the wiki, but to no avail. Unless there is documentation on
what needs to be done, doing it will be hopeless and waiting for the
packaging system to updated means portmaster WILL be broken for some period
of time.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: The future of portmaster [and of ports-mgmt/synth]

[Mark Linimon]

On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote:
> Hello, I have not followed this thread before but just wanted to say
> that I use portmaster extensively, it works for us and I would miss
> it if it went.  Are there actually plans to retire it?

To reiterate the status:

 * some extensive changes to the ports framework are coming;
 * these will require large changes to all the port upgrade tools;
 * no one has stepped forwards to offer to do the work for anything
   other than poudriere AFAIK.

If no one does the work, at the time the large changes come, the
other tools will break.

People have been wanting subpackages (aka flavors) for many years;
IIUC these are parts of the changes that are coming.

Someone needs to step forwards and say "yes, I will do the work."

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: The future of portmaster [and of ports-mgmt/synth]

[Per olof Ljungmark]

On 2017-05-30 22:06, Mark Linimon wrote:

On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote:

Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017


I really suggest that you look at synth.


synth is currently only available for x86 and unless someone steps up
to do the work to make the Ada compilers run on the other architectures
that is certain to remain to the case.


Hello, I have not followed this thread before but just wanted to say 
that I use portmaster extensively, it works for us and I would miss it 
if it went. Are there actually plans to retire it? Hope I didn't miss 
something.


Just my $0.02... //per
___
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: The future of portmaster [and of ports-mgmt/synth]

[Ed Maste]

On 30 May 2017 at 15:00, Mark Millard  wrote:
>
> ports-mgmt/synth depends on lang/gcc6-aux

For reference, I've created PR 219667 to track the lang/gcc6-aux
issue. The pre-built bootstrap compilers need to be recreated I
believe, with a trick similar to the one used for lang/ghc.
___
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: The future of portmaster

[Jim Ohlstein]

On Tue, 2017-05-30 at 14:25 -0600, Adam Weinberger wrote:
> > On 30 May, 2017, at 14:19, Thomas Mueller 
> > wrote:
> > 
> > 
> > One thing I forgot to mention in my last post is that the UPDATING
> > file looks geared to portmaster and portupgrade.
> > 
> > Users are thus led to believe that portupgrade and portmaster are
> > still the currently recommended tools.
> > 
> > If the ports people want to get users to switch to synth or
> > poudriere, updating instructions should include synth and
> > poudriere.
> 
> There are no updating instructions for them. They do the right thing
> automatically. Only portmaster needs its hand held every time
> something gets updated.
> 
> The only difference is that things go into a make.conf in
> /usr/local/etc/poudriere.d/ rather than /etc/make.conf (see
> CUSTOMISATION in poudriere(8) for details), and I don't know if synth
> has a special place for it too.
> 

And not only that, but poudriere reads MOVED as well.

> 
-- 
Jim Ohlstein
Professional Mailman Hosting
https://mailman-hosting.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: The future of portmaster

[Adam Weinberger]

> On 30 May, 2017, at 14:19, Thomas Mueller  wrote:
> 
> 
> One thing I forgot to mention in my last post is that the UPDATING file looks 
> geared to portmaster and portupgrade.
> 
> Users are thus led to believe that portupgrade and portmaster are still the 
> currently recommended tools.
> 
> If the ports people want to get users to switch to synth or poudriere, 
> updating instructions should include synth and poudriere.

There are no updating instructions for them. They do the right thing 
automatically. Only portmaster needs its hand held every time something gets 
updated.

The only difference is that things go into a make.conf in 
/usr/local/etc/poudriere.d/ rather than /etc/make.conf (see CUSTOMISATION in 
poudriere(8) for details), and I don't know if synth has a special place for it 
too.

# 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: The future of portmaster

[Thomas Mueller]

One thing I forgot to mention in my last post is that the UPDATING file looks 
geared to portmaster and portupgrade.

Users are thus led to believe that portupgrade and portmaster are still the 
currently recommended tools.

If the ports people want to get users to switch to synth or poudriere, updating 
instructions should include synth and poudriere.


Tom

___
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: The future of portmaster [and of ports-mgmt/synth]

[Mark Linimon]

On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote:
> Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017
> 
> > I really suggest that you look at synth.

synth is currently only available for x86 and unless someone steps up
to do the work to make the Ada compilers run on the other architectures
that is certain to remain to the case.

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: The future of portmaster [and of ports-mgmt/synth]

[Mark Millard]

Adam Weinberger adamw at adamw.org wrote on Tue May 30 14:00:21 UTC 2017:

> poudriere and synth are actively developed

Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017

> I really suggest that you look at synth.

ports-mgmt/synth depends on lang/gcc6-aux which
has lost its maintainer --and is broken for
FreeBSD head after the ino64 changes. (synth
was written in ada --which is not directly
available from the normal lang/gcc* 's.) This
broken status includes amd64 now.

(The lang/gcc6-aux maintainer was also the
author/creator.)

A similar status happened for ports-mgmt/synth
relative to its newly claimed aarch64 support:
lang/gcc6-aux turned out to be broken such that
it would not build on aarch64, which in turn
stopped ports-mgmt/synth builds. . .

ports-mgmt/synth -r437524 (Sun Apr 2) reported:

> ports-mgmt/synth: update 1.68 -> 1.69
> 

> - FreeBSD/ARM* support

but by the time I tried I could not build it
because I could not build lang/gcc6-aux on a
Pine64+ 2GB: head's system headers vs. gcc
munging of copies them were no longer matched
in the bootstrap process that lang/gcc6-aux
uses. This is still true even without
progressing to the ino64 changes in FreeBSD's
head (12-CURRENT).

Unfortunately ports-mgmt/synth suffers from
build prerequisites that do not have a wide
range of contributing maintainers or otherwise
broad support. This looks like it will make
ports-mgmt/synth problematical as things are.

===
Mark Millard
markmi at dsl-only.net

___
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: The future of portmaster

[Adam Weinberger]

> On 30 May, 2017, at 11:37, Peter Beckman  wrote:
> 
> On Tue, 30 May 2017, Adam Weinberger wrote:
> 
>> You don't need separate port trees. The idea is to use poudriere to build
>> ALL your ports. Just make a list of the ports you want, pass it to
>> poudriere, and it will keep everything up-to-date, rebuild things when
>> they need to be rebuilt, and give you a pkg repository so you can just
>> run "pkg install foo" or "pkg upgrade" to keep your system running.
>> 
>> Even if you do use poudriere to build only a few ports, it's pretty easy.
>> Give your own generated packages a higher priority in
>> /usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo
>> above the upstream repo.
> 
> Where is this seemingly super easy process documented? Yes, I can read the
> docs and try to figure out the "best practice" workflow, or someone with
> amazing knowledge of poudriere (and/or synth) can write a "here's how to
> manage your ports" best practices for the occasional sysadmin, rather than
> the hard-core supporting a fleet of FreeBSD boxes admin.
> 
> I've looked before and never found such a document. Something from the
> portupgrade or portmaster user POV, and why and how to move to the more
> modern and actively developed tools.

/usr/local/etc/pkg/repos/local.conf:
Local: {
url:file:///zroot/poudriere/data/packages/JAILNAME,
priority: 10
}

Then, "pkg install foo" will first look for foo in your generated packages, and 
fall back to the upstream pkg repository.

If you use poudriere to build all your ports, just add this to turn upstream 
off entirely:
/usr/local/etc/pkg/repos/FreeBSD.conf:
FreeBSD: { enabled: no }

>> So no, you don't need separate ports trees. poudriere is happiest though
>> when you let it manage its own ports tree, so I prefer to just symlink
>> /usr/ports to it, but you can very easily use a pre-existing ports tree
>> with poudriere.
> 
> You make it sound so easy! Maybe it is, but I haven't found it.

Check out https://github.com/freebsd/poudriere/wiki/use_system_ports_tree for 
some instructions on how to use a system ports tree.

Personally, I prefer to let poudriere's tree be the main one:
( Remove your old ports tree first; keep the distfiles around if you'd like)
# poudriere ports -c (Skip this if you already created a poudriere tree)
# ln -s /zroot/poudriere/ports/default /usr/ports

# 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: The future of portmaster

[Peter Beckman]

On Tue, 30 May 2017, Adam Weinberger wrote:


You don't need separate port trees. The idea is to use poudriere to build
ALL your ports. Just make a list of the ports you want, pass it to
poudriere, and it will keep everything up-to-date, rebuild things when
they need to be rebuilt, and give you a pkg repository so you can just
run "pkg install foo" or "pkg upgrade" to keep your system running.

Even if you do use poudriere to build only a few ports, it's pretty easy.
Give your own generated packages a higher priority in
/usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo
above the upstream repo.


 Where is this seemingly super easy process documented? Yes, I can read the
 docs and try to figure out the "best practice" workflow, or someone with
 amazing knowledge of poudriere (and/or synth) can write a "here's how to
 manage your ports" best practices for the occasional sysadmin, rather than
 the hard-core supporting a fleet of FreeBSD boxes admin.

 I've looked before and never found such a document. Something from the
 portupgrade or portmaster user POV, and why and how to move to the more
 modern and actively developed tools.


So no, you don't need separate ports trees. poudriere is happiest though
when you let it manage its own ports tree, so I prefer to just symlink
/usr/ports to it, but you can very easily use a pre-existing ports tree
with poudriere.


 You make it sound so easy! Maybe it is, but I haven't found it.

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.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: The future of portmaster

[Thomas Mueller]

> The ports tree continues to evolve. Major new features are planned and in the 
> process of being implemented. These changes will break all the port-building 
> tools.

> poudriere and synth are actively developed, so they will quickly support the 
> new changes. portmaster and portupgrade are no longer being actively 
> developed, so it is anticipated that they will stop working until somebody 
> fixes
> them (if at all).

> So no, portmaster isn't going away. But, there's no guarantee that it will 
> keep working. We strongly, strongly advise everyone to use poudriere or synth 
> to build their ports, and then plain old "pkg upgrade" to handle updates.

> The vast majority of problems reported on this mailing list exist only in 
> portmaster/portupgrade, because they do not do clean builds. At this point, 
> portmaster should only be used by people with enough ports development
> experience to understand and mitigate conflicts and various build errors.

# Adam


> Adam Weinberger

I remember the days when some FreeBSD users swore by portmanager, but 
subsequent changes to ports framework rendered portmanager unworkable.  I never 
used portmanager.

I used portupgrade but switched to portmaster.

First attempt to build synth failed on FreeBSD-current when the system crashed 
and rebooted as I was sleeping, so maybe not synth's fault.

Now I see it might be impossible to build synth on FreeBSD-current due to some 
ports, including lang/gcc5-aux and lang/gcc6-aux, not building following the 
change to ino64; lang/gcc6-aux is a dependency of synth.

But I suppose this will be patched, hopefully in the near future.

I noticed that synth was ported to NetBSD along with pkg, but see nothing on 
NetBSD emailing lists regarding synth.

Maybe synth is not catching on in NetBSD; pkgsrc users seem to be staying with 
pkg_* tools like in FreeBSD before the switch to pkgng.  Big nuisance updating 
packages whose names have changed.

Tom

___
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: The future of portmaster

[Kevin Oberman]

On Tue, May 30, 2017 at 7:15 AM, Anton Shterenlikht 
wrote:

> >From ad...@adamw.org Tue May 30 15:03:31 2017
> >
> >The ports tree continues to evolve. Major new features are planned and in
> the process of being implemented. These changes will break all the
> port-building tools.
>
> oy vei
>
> >poudriere and synth are actively developed, so they will quickly support
> the new changes. portmaster and portupgrade are no longer being actively
> developed, so it is anticipated that they will stop working until somebody
> fixes them (if at all).
>
> I last used poudriere a couple years back.
> It is much more involved than portmaster
> (obviously, these 2 tools are not doing the same job)
>
> >So no, portmaster isn't going away. But, there's no guarantee that it
> will keep working. We strongly, strongly advise everyone to use poudriere
> or synth to build their ports, and then plain old "pkg upgrade" to handle
> updates.
>
> because my experience of poudriere was mixed,
> I haven't used it at all on amd64.
> pkg is great. And when occasionally I need
> non-default options I use portmaster.
>
> >
> >The vast majority of problems reported on this mailing list exist only in
> portmaster/portupgrade, because they do not do clean builds. At this point,
> portmaster should only be used by people with enough ports development
> experience to understand and mitigate conflicts and various build errors.
>
> I agree that a dirty environement is mostly
> the source of bad portmaster builds.
>
> However, to create the whole poudriere enviroment
> to build a port a week, or maybe a month, seems
> like an overkill.
>
> Yes, I know, it's a volunteer project, things
> evolve, unless somebody steps in...
>
> If my recollection of poudriere is correct,
> I'll need a separate ports tree?
> And if I only need to build a single port
> with custom settings, I'll have to start
> every time from scratch?
> And if I want to use this single port with
> default settings with my other ports, I need
> to make sure the 2 port trees are in sync.
>
> Sorry if I don't do poudeire justice, it's been a while...
>
> Anton
> ___
> 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"
>

I really suggest that you look at synth. It also builds in a clean
environment and provides all of the advantages of poudeire for use in a
single-system (or multiple identical systems) case. No jails to set up. It
builds a local pkg repository and you then use pkg on everything. I don't
consider it a replacement for portmaster, but in most environments it does
the same job and, since it builds in a clean environment, it avoids many of
the issues with other tools. It is also very well documented, so it is not
too hard to understand setup and use.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: The future of portmaster

[Jeffrey Bouquet via freebsd-ports]

tl/dr at bottom, repeated here,   flowchart please


On Tue, 5/30/17, Adam Weinberger <ad...@adamw.org> wrote:

 Subject: Re: The future of portmaster
 To: me...@bris.ac.uk
 Cc: rollingb...@gmail.com, freebsd-ports@freebsd.org
 Date: Tuesday, May 30, 2017, 7:30 AM
 
 > On 30 May, 2017, at 8:15,
 Anton Shterenlikht <me...@bris.ac.uk>
 wrote:
 > 
 >> From
 ad...@adamw.org
 Tue May 30 15:03:31 2017
 >> 
 >> The ports tree continues to evolve.
 Major new features are planned and in the process of being
 implemented. These changes will break all the port-building
 tools.
 > 
 > oy vei
 > 
 >> poudriere and
 synth are actively developed, so they will quickly support
 the new changes. portmaster and portupgrade are no longer
 being actively developed, so it is anticipated that they
 will stop working until somebody fixes them (if at all).
 > 
 > I last used
 poudriere a couple years back.
 > It is
 much more involved than portmaster
 >
 (obviously, these 2 tools are not doing the same job)
 
 There's definitely more
 work up-front to set up poudriere. You get the effort back,
 though, in long-term viability and not having to chase
 problems up and down the ports tree.
 
 >> So no, portmaster isn't going
 away. But, there's no guarantee that it will keep
 working. We strongly, strongly advise everyone to use
 poudriere or synth to build their ports, and then plain old
 "pkg upgrade" to handle updates.
 > 
 > because my
 experience of poudriere was mixed,
 > I
 haven't used it at all on amd64.
 >
 pkg is great. And when occasionally I need
 > non-default options I use portmaster.
 > 
 >> 
 >> The vast majority of problems reported
 on this mailing list exist only in portmaster/portupgrade,
 because they do not do clean builds. At this point,
 portmaster should only be used by people with enough ports
 development experience to understand and mitigate conflicts
 and various build errors.
 > 
 > I agree that a dirty environement is
 mostly
 > the source of bad portmaster
 builds.
 > 
 > However,
 to create the whole poudriere enviroment
 > to build a port a week, or maybe a month,
 seems
 > like an overkill.
 > 
 > Yes, I know,
 it's a volunteer project, things
 >
 evolve, unless somebody steps in...
 > 
 > If my recollection of poudriere is
 correct,
 > I'll need a separate ports
 tree?
 > And if I only need to build a
 single port
 > with custom settings,
 I'll have to start
 > every time from
 scratch?
 > And if I want to use this
 single port with
 > default settings with
 my other ports, I need
 > to make sure the
 2 port trees are in sync.
 > 
 > Sorry if I don't do poudeire justice,
 it's been a while...
 
 You don't need separate port trees. The
 idea is to use poudriere to build ALL your ports. Just make
 a list of the ports you want, pass it to poudriere, and it
 will keep everything up-to-date, rebuild things when they
 need to be rebuilt, and give you a pkg repository so you can
 just run "pkg install foo" or "pkg
 upgrade" to keep your system running.
 
 Even if you do use poudriere
 to build only a few ports, it's pretty easy. Give your
 own generated packages a higher priority in
 /usr/local/etc/pkg/repos/ and you can transparently layer
 your pkg repo above the upstream repo.
 
 So no, you don't need separate ports trees.
 poudriere is happiest though when you let it manage its own
 ports tree, so I prefer to just symlink /usr/ports to it,
 but you can very easily use a pre-existing ports tree with
 poudriere.
 
 # 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"
 

Sorry for the yahoo webclient not quoting the above.
If applicable.
Leaving aside my wishes for the /usr/ports/MOVED/portmanager *also* eventually 
back
upto speed with portmaster, even as shareware, this poudriere and even synth I 
think
could benefit from a flowchart...  right side differing scenarios what one's 
goals are 
left and work backwards thru all the things can go wrong, dotted boxes 'errors' 
and
arrows to the solution(s) paths, [ and  a third part of this flowchart I just 
thought of
...] and on the left simple boxes, like one server one lan, two servers two lan,
one server a VPN three hundred downstream 'subscriber' clients for the built 
ports,
and any other things, more visually explained than a much longer wiki reading.

tl/dr  flowchart please
___
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: The future of portmaster

[Adam Weinberger]

> On 30 May, 2017, at 8:15, Anton Shterenlikht  wrote:
> 
>> From ad...@adamw.org Tue May 30 15:03:31 2017
>> 
>> The ports tree continues to evolve. Major new features are planned and in 
>> the process of being implemented. These changes will break all the 
>> port-building tools.
> 
> oy vei
> 
>> poudriere and synth are actively developed, so they will quickly support the 
>> new changes. portmaster and portupgrade are no longer being actively 
>> developed, so it is anticipated that they will stop working until somebody 
>> fixes them (if at all).
> 
> I last used poudriere a couple years back.
> It is much more involved than portmaster
> (obviously, these 2 tools are not doing the same job)

There's definitely more work up-front to set up poudriere. You get the effort 
back, though, in long-term viability and not having to chase problems up and 
down the ports tree.

>> So no, portmaster isn't going away. But, there's no guarantee that it will 
>> keep working. We strongly, strongly advise everyone to use poudriere or 
>> synth to build their ports, and then plain old "pkg upgrade" to handle 
>> updates.
> 
> because my experience of poudriere was mixed,
> I haven't used it at all on amd64.
> pkg is great. And when occasionally I need
> non-default options I use portmaster.
> 
>> 
>> The vast majority of problems reported on this mailing list exist only in 
>> portmaster/portupgrade, because they do not do clean builds. At this point, 
>> portmaster should only be used by people with enough ports development 
>> experience to understand and mitigate conflicts and various build errors.
> 
> I agree that a dirty environement is mostly
> the source of bad portmaster builds.
> 
> However, to create the whole poudriere enviroment
> to build a port a week, or maybe a month, seems
> like an overkill.
> 
> Yes, I know, it's a volunteer project, things
> evolve, unless somebody steps in...
> 
> If my recollection of poudriere is correct,
> I'll need a separate ports tree?
> And if I only need to build a single port
> with custom settings, I'll have to start
> every time from scratch?
> And if I want to use this single port with
> default settings with my other ports, I need
> to make sure the 2 port trees are in sync.
> 
> Sorry if I don't do poudeire justice, it's been a while...

You don't need separate port trees. The idea is to use poudriere to build ALL 
your ports. Just make a list of the ports you want, pass it to poudriere, and 
it will keep everything up-to-date, rebuild things when they need to be 
rebuilt, and give you a pkg repository so you can just run "pkg install foo" or 
"pkg upgrade" to keep your system running.

Even if you do use poudriere to build only a few ports, it's pretty easy. Give 
your own generated packages a higher priority in /usr/local/etc/pkg/repos/ and 
you can transparently layer your pkg repo above the upstream repo.

So no, you don't need separate ports trees. poudriere is happiest though when 
you let it manage its own ports tree, so I prefer to just symlink /usr/ports to 
it, but you can very easily use a pre-existing ports tree with poudriere.

# 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: The future of portmaster

[Anton Shterenlikht]

>From ad...@adamw.org Tue May 30 15:03:31 2017
>
>The ports tree continues to evolve. Major new features are planned and in the 
>process of being implemented. These changes will break all the port-building 
>tools.

oy vei

>poudriere and synth are actively developed, so they will quickly support the 
>new changes. portmaster and portupgrade are no longer being actively 
>developed, so it is anticipated that they will stop working until somebody 
>fixes them (if at all).

I last used poudriere a couple years back.
It is much more involved than portmaster
(obviously, these 2 tools are not doing the same job)

>So no, portmaster isn't going away. But, there's no guarantee that it will 
>keep working. We strongly, strongly advise everyone to use poudriere or synth 
>to build their ports, and then plain old "pkg upgrade" to handle updates.

because my experience of poudriere was mixed,
I haven't used it at all on amd64.
pkg is great. And when occasionally I need
non-default options I use portmaster.

>
>The vast majority of problems reported on this mailing list exist only in 
>portmaster/portupgrade, because they do not do clean builds. At this point, 
>portmaster should only be used by people with enough ports development 
>experience to understand and mitigate conflicts and various build errors.

I agree that a dirty environement is mostly
the source of bad portmaster builds.

However, to create the whole poudriere enviroment
to build a port a week, or maybe a month, seems
like an overkill.

Yes, I know, it's a volunteer project, things
evolve, unless somebody steps in...

If my recollection of poudriere is correct,
I'll need a separate ports tree?
And if I only need to build a single port
with custom settings, I'll have to start
every time from scratch?
And if I want to use this single port with
default settings with my other ports, I need
to make sure the 2 port trees are in sync.

Sorry if I don't do poudeire justice, it's been a while...

Anton
___
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: The future of portmaster

[Adam Weinberger]

> On 30 May, 2017, at 7:51, Anton Shterenlikht  wrote:
> 
>> when portmaster have gone away?
> 
> What? WHAT?
> 
> portmaster going away???
> 
> I hope not
> 
> Anton

The ports tree continues to evolve. Major new features are planned and in the 
process of being implemented. These changes will break all the port-building 
tools.

poudriere and synth are actively developed, so they will quickly support the 
new changes. portmaster and portupgrade are no longer being actively developed, 
so it is anticipated that they will stop working until somebody fixes them (if 
at all).

So no, portmaster isn't going away. But, there's no guarantee that it will keep 
working. We strongly, strongly advise everyone to use poudriere or synth to 
build their ports, and then plain old "pkg upgrade" to handle updates.

The vast majority of problems reported on this mailing list exist only in 
portmaster/portupgrade, because they do not do clean builds. At this point, 
portmaster should only be used by people with enough ports development 
experience to understand and mitigate conflicts and various build errors.

# 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: The future of portmaster

[Anton Shterenlikht]

>when portmaster have gone away?

What? WHAT?

portmaster going away???

I hope not

Anton
___
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: The future of portmaster

[rollingbits (Lucas)]

On Feb 22, 2017 11:36 AM, "rollingbits (Lucas)" 
wrote:

On Feb 19, 2017 12:13 PM, "Matthias Andree"  wrote:

Am 17.02.2017 um 08:37 schrieb abi:
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment.

Please use poudriere or some other tool instead, there are some that
were designed for clean-room rebuilds, which portmaster was *not*
designed to do, and should not be turned into.


Just out of curiosity, as bad software build interactions shows itself only
in dirty environments, what is the tool that will catch this kind of bug
when portmaster have gone away?


Sorry for the double post.

I'm not trying to answer myself but then are you peoples proposing fix the
ports in a way that a "make upgrade" will do the right thing now that there
is a better package system and this will let us drop solutions as
postmaster?

Lc
___
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: The future of portmaster

[rollingbits (Lucas)]

On Feb 22, 2017 11:36 AM, "rollingbits (Luc wrote:

On Feb 19, 2017 12:13 PM, "Matthias Andree"  wrote:

Am 17.02.2017 um 08:37 schrieb abi:
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment.

Please use poudriere or some other tool instead, there are some that
were designed for clean-room rebuilds, which portmaster was *not*
designed to do, and should not be turned into.


Just out of curiosity, as bad software build interactions shows itself only
in dirty environments, what is the tool that will catch this kind of bug
when portmaster have gone away?

Lc

-- 
rollingbits --  rollingb...@gmail.com  rollingb...@terra.com.br
 rollingb...@yahoo.com  rollingb...@globo.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: The future of portmaster

[rollingbits (Lucas)]

On Feb 19, 2017 12:13 PM, "Matthias Andree"  wrote:

Am 17.02.2017 um 08:37 schrieb abi:
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment.

Please use poudriere or some other tool instead, there are some that
were designed for clean-room rebuilds, which portmaster was *not*
designed to do, and should not be turned into.


Just out of curiosity, as bad software build interactions shows itself only
in dirty environments, what is the tool that will catch this kind of bug
when portmaster have gone away?

Lc

-- 
rollingbits --  rollingb...@gmail.com  rollingb...@terra.com.br
 rollingb...@yahoo.com  rollingb...@globo.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: The future of portmaster

[Matthias Andree]

Am 19.02.2017 um 20:21 schrieb Baho Utot:

> How about I will use what _I_ find necessary.  BTW I am using Synth. 

Oh, absolutely. portmaster just doesn't do what you find necessary today.
___
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: The future of portmaster

[Baho Utot]

On 02/19/17 10:04, Matthias Andree wrote:

Am 16.02.2017 um 21:48 schrieb Baho Utot:

Having built and packaged linux from scratch using the rpm package
manager, I came to find that if one is building packages to be used on
multiple machines, one needs to build each package in a chroot
environment or the package could inherit things from the parent not
found in the target machine.  Here by making the package unusable.



We used to have Tinderbox for the purpose, and now we have Poudriere,
please use that for your purpose.
Portmaster is, by contrast, a tool that focuses on rebuilding a port
using, well, the port in the existing system,
without building a gazillion of requisite other ports for the chroot
first, which easily ends up building some 400 packages when you just
want a convenient way to update ONE port, perhaps with a special
configuration.



How about I will use what _I_ find necessary.  BTW I am using Synth.


___
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: The future of portmaster

[Matthias Andree]

Am 17.02.2017 um 08:37 schrieb abi:
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment. 

Please use poudriere or some other tool instead, there are some that
were designed for clean-room rebuilds, which portmaster was *not*
designed to do, and should not be turned into.
___
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: The future of portmaster

[Matthias Andree]

Am 16.02.2017 um 21:48 schrieb Baho Utot:
> Having built and packaged linux from scratch using the rpm package
> manager, I came to find that if one is building packages to be used on
> multiple machines, one needs to build each package in a chroot
> environment or the package could inherit things from the parent not
> found in the target machine.  Here by making the package unusable.
>

We used to have Tinderbox for the purpose, and now we have Poudriere,
please use that for your purpose.
Portmaster is, by contrast, a tool that focuses on rebuilding a port
using, well, the port in the existing system,
without building a gazillion of requisite other ports for the chroot
first, which easily ends up building some 400 packages when you just
want a convenient way to update ONE port, perhaps with a special
configuration.
___
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: The future of portmaster

[Matthias Andree]

Am 17.02.2017 um 09:25 schrieb Matthieu Volat:
> Just dropping privileges to a dedicated user for building would be a
> big step, but that's more a port feature (openbsd's ports do that, if
> I'm not wrong).

With a distfiles directory writable to the unprivileged user doing the
build, and sudo as a privilege escalation tool for the same user, you
can do major parts of the build as unprivileged user with existing
versions already. No need to run portmaster as root.

___
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: The future of portmaster

[Peter Jeremy]

On 2017-Feb-17 19:03:31 +0100, Luca Pizzamiglio  
wrote:
>* dropping privileges is really a nice feature to add. The portstree
>allow you to build everything as normal user, so portmaster can be
>able to do it as well.

I use portmaster as a normal user without problems so I'm not sure what
the "new feature" bit would be, other than in conjunction with chroot/jail.

>* show flags when build fails should be doable

The non-trivial part of this is making it show the flags that are relevant
to updating the ports specified in the remaining output.  This will normally
be different to the flags that portmaster was initially invoked with.

>--packages-only|-PP : it looks redundant to me

I used to use this, prior to pkgng, to let me build/upgrade packages on one
system and then install/upgrade them on a second (much slower) system.  I
believe all this functionality is now subsumed into pkgng.

>I'm also considering to remove, if nobody is using them:
>* +IGNOREME support (a file saved in /var/db/pkg/ to force 
>ignore)

This is a bit of a wart following the pkg_* to pkgng migration but I currently
use this for two purposes:
1) On a slow system, it's a convenient way to postpone updating a large port
without having to individually say yes/no to each port with -i.  Having 
portmaster
obey "locked" packages would remove this use but currently portmaster ignores
"locked" flags and blows up.
2) I have some work-in-progress "ports" that are in my home directory, rather
than under /usr/ports.  Again, creating something like /usr/ports/local as a
new SUBDIR would probably be a better approach.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The future of portmaster

[Luca Pizzamiglio]

Hi all,

thanks for all the replies.

To summarize:
* chroot/jails build could be a nice feature, but it will be an
option, not a requirement. I understand the needs to build in a clean
environment (poudriere and synth works in this direction for a good
reason), but as port maintainer, building in a "dirty" environment
detects this kind of configure problems (library auto-detected or
auto-enabled) that a clean environment cannot shows.
* dropping privileges is really a nice feature to add. The portstree
allow you to build everything as normal user, so portmaster can be
able to do it as well.
* show flags when build fails should be doable
* the dependency order is something I'd like to work on, also to
improve the internal management

I'd like to re-enabling at least --packages-build, that can be really useful.
I'll remove:
--packages-only|-PP : it looks redundant to me
-e : as above, it's redundant; to remove distfiles, --clean-distfiles
can be used after a pkg delete

I'm also considering to remove, if nobody is using them:
* all the --index options, but only
* +IGNOREME support (a file saved in /var/db/pkg/ to force ignore)

No ETA, but I'll do my best.

Best regards,
pizzamig



On Fri, Feb 17, 2017 at 5:55 PM, Chris H  wrote:
> On Fri, 17 Feb 2017 10:37:16 +0300 abi  wrote
>
>> 17.02.2017 00:22, Chris H пишет:
>> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot 
>> > wrote >
>> >> On 02/16/17 15:40, George Mitchell wrote:
>> >>> On 02/16/17 15:33, Baho Utot wrote:
>> 
>>  On 02/16/17 14:01, Lowell Gilbert wrote:
>> > Baho Utot  writes:
>> >
>> >> On 02/16/17 06:08, Luca Pizzamiglio wrote:
>> >>> I'm looking for constructive critics, feedbacks, anything that can
>> >>> help me to make portmaster an actively maintained and used tool.
>> >> If you can have it build in a clean chroot or jail then you'll get my
>> >> attention
>> > What kind of special support?
>> >
>> > I use it with a chroot that mounts /usr/ports (and src) read-only, and
>> > aside from the initial base system install, it took about fifteen
>> > minutes to set up.
>> >
>>  Using chroot or jails to build each individual package
>>  [...]
>> >>> While I understand the interest in chroot/jails as an optional
>> >>> feature, I hope it doesn't become required.  The current non-use
>> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
>> >>>
>> >>>
>> >> Having built and packaged linux from scratch using the rpm package
>> >> manager, I came to find that if one is building packages to be used on
>> >> multiple machines, one needs to build each package in a chroot
>> >> environment or the package could inherit things from the parent not
>> >> found in the target machine.  Here by making the package unusable.
>> > Hello. You shouldn't have any difficulty accomplishing your goal
>> > by simply setting up a jail, and using portmaster within that jail(8).
>> > portmaster really doesn't care where it's run. So long as it has
>> > everything it needs to accomplish it's job(s). :-)
>> >
>>  From my point of view, jails are overkill. Chroot should be enough and
>> it would be nice if portmaster starts building in clean environment.
> Oh, I won't argue that. Indeed, chroot(8) is a much lighter solution.
> But for my needs, jail(8) is the best solution. As I've already setup
> a number for other tasks, anyway.
> Speaking of chroot(8), synth(1) chroots all its work.
>
> All the best.
>
> --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: The future of portmaster

[Chris H]

On Fri, 17 Feb 2017 10:37:16 +0300 abi  wrote

> 17.02.2017 00:22, Chris H пишет:
> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot 
> > wrote >
> >> On 02/16/17 15:40, George Mitchell wrote:
> >>> On 02/16/17 15:33, Baho Utot wrote:
> 
>  On 02/16/17 14:01, Lowell Gilbert wrote:
> > Baho Utot  writes:
> >
> >> On 02/16/17 06:08, Luca Pizzamiglio wrote:
> >>> I'm looking for constructive critics, feedbacks, anything that can
> >>> help me to make portmaster an actively maintained and used tool.
> >> If you can have it build in a clean chroot or jail then you'll get my
> >> attention
> > What kind of special support?
> >
> > I use it with a chroot that mounts /usr/ports (and src) read-only, and
> > aside from the initial base system install, it took about fifteen
> > minutes to set up.
> >
>  Using chroot or jails to build each individual package
>  [...]
> >>> While I understand the interest in chroot/jails as an optional
> >>> feature, I hope it doesn't become required.  The current non-use
> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
> >>>
> >>>
> >> Having built and packaged linux from scratch using the rpm package
> >> manager, I came to find that if one is building packages to be used on
> >> multiple machines, one needs to build each package in a chroot
> >> environment or the package could inherit things from the parent not
> >> found in the target machine.  Here by making the package unusable.
> > Hello. You shouldn't have any difficulty accomplishing your goal
> > by simply setting up a jail, and using portmaster within that jail(8).
> > portmaster really doesn't care where it's run. So long as it has
> > everything it needs to accomplish it's job(s). :-)
> >
>  From my point of view, jails are overkill. Chroot should be enough and 
> it would be nice if portmaster starts building in clean environment.
Oh, I won't argue that. Indeed, chroot(8) is a much lighter solution.
But for my needs, jail(8) is the best solution. As I've already setup
a number for other tasks, anyway.
Speaking of chroot(8), synth(1) chroots all its work.

All the best.

--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: The future of portmaster

[George Mitchell]

On 02/17/17 02:37, abi wrote:
> 17.02.2017 00:22, Chris H пишет:
>> On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot
>>  wrote
>>
>>> [...]
>> Hello. You shouldn't have any difficulty accomplishing your goal
>> by simply setting up a jail, and using portmaster within that jail(8).
>> portmaster really doesn't care where it's run. So long as it has
>> everything it needs to accomplish it's job(s). :-)
>>
> From my point of view, jails are overkill. Chroot should be enough and
> it would be nice if portmaster starts building in clean environment.
> 
Some of us might even consider chroot overkill.  I'm fine with a
chroot option, but let's not turn portmaster into something that
unconditionally requires more resources than the underlying build
needs.  -- George




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[Baptiste Daroussin]

On Thu, Feb 16, 2017 at 12:08:52PM +0100, Luca Pizzamiglio wrote:
> Hi all,
> 
> portmaster, a tool used/loved/hated, is almost in abandoned state.
> I'm a portmaster user, because, in some cases, it fits my needs.
> In other cases, I use other tools, like poudriere or synth, that are
> really great.
> I don't want to open a discussion here about what it's better, but the
> truth is, that I use portmaster and it's not maintained.
> So I decided to spend some time to look at it and to work on it.
> 
> I forked it and I start some work.
> The plan is:
> - remove obsolete features, like the -PP option
> - remove pkg_* support (even if someone could be against it), forcing
> the usage of pkg
> - prepare the support of new features like FLAVORS and subpackages
> - adding a new ports, called portmaster-devel, for the new version
> 
> I did a branch on github working of the first two points
> (https://github.com/pizzamig/portmaster/tree/remove_oldpkg)
> 
> I'm looking for constructive critics, feedbacks, anything that can
> help me to make portmaster an actively maintained and used tool.
> 
> Thanks in advance
> 
> Best regards,
> pizzamig
> 
> PS: I won't start a port/pkg tool war, my opinion is that the world is
> big enough to have poudriere, synth, portmaster, portupgrade and
> whatever tool you will write to handle/build any ports package in the
> way that you prefer.

Glad to see someone will to work on it.

On your work please make sure the minimize the dependency on origin being a
unique identifier. We are working on having subpackages, flavors which means
multiple packages would have the same origin.

If we want to keep portmaster working it has to grow the knowledge of multiple
packages can have the same origin.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: The future of portmaster

[Jan Bramkamp]

On 17/02/2017 09:25, Matthieu Volat wrote:

On Fri, 17 Feb 2017 10:37:16 +0300
abi  wrote:


17.02.2017 00:22, Chris H пишет:

On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot  wrote


On 02/16/17 15:40, George Mitchell wrote:

On 02/16/17 15:33, Baho Utot wrote:


On 02/16/17 14:01, Lowell Gilbert wrote:

Baho Utot  writes:


On 02/16/17 06:08, Luca Pizzamiglio wrote:

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.

If you can have it build in a clean chroot or jail then you'll get my
attention

What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.


Using chroot or jails to build each individual package
[...]

While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George



Having built and packaged linux from scratch using the rpm package
manager, I came to find that if one is building packages to be used on
multiple machines, one needs to build each package in a chroot
environment or the package could inherit things from the parent not
found in the target machine.  Here by making the package unusable.

Hello. You shouldn't have any difficulty accomplishing your goal
by simply setting up a jail, and using portmaster within that jail(8).
portmaster really doesn't care where it's run. So long as it has
everything it needs to accomplish it's job(s). :-)


 From my point of view, jails are overkill. Chroot should be enough and
it would be nice if portmaster starts building in clean environment.


Just dropping privileges to a dedicated user for building would be a big step, 
but that's more a port feature (openbsd's ports do that, if I'm not wrong).


Yes dropping privileges would be a good *additional* step. The purpose 
of the jail/chroot isn't just for security. The real goal is to provide 
a reproducible, clean build environment. Lots of broken configure 
scripts out there include a lot of autodetection magic. And suddenly 
your binaries are link against additional libraries which are unknown to 
pkg. This becomes even funnier if your application uses fork+exec per 
connection. Suddenly you're left with a bound socket but each connection 
dies because the worker fails to link at runtime. This was the straw 
that broke the camels back for me. An other problem with portmaster is 
that it creates inconsistent during the upgrade by design. Of course pkg 
upgrade isn't atomic either but the time window is on the order of a few 
seconds instead of minutes to hours and is far less likely fail halfway 
through.

___
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: The future of portmaster

[Matthieu Volat]

On Fri, 17 Feb 2017 10:37:16 +0300
abi  wrote:

> 17.02.2017 00:22, Chris H пишет:
> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot  
> > wrote
> >
> >> On 02/16/17 15:40, George Mitchell wrote:
> >>> On 02/16/17 15:33, Baho Utot wrote:
> 
>  On 02/16/17 14:01, Lowell Gilbert wrote:
> > Baho Utot  writes:
> >
> >> On 02/16/17 06:08, Luca Pizzamiglio wrote:
> >>> I'm looking for constructive critics, feedbacks, anything that can
> >>> help me to make portmaster an actively maintained and used tool.
> >> If you can have it build in a clean chroot or jail then you'll get my
> >> attention
> > What kind of special support?
> >
> > I use it with a chroot that mounts /usr/ports (and src) read-only, and
> > aside from the initial base system install, it took about fifteen
> > minutes to set up.
> >
>  Using chroot or jails to build each individual package
>  [...]
> >>> While I understand the interest in chroot/jails as an optional
> >>> feature, I hope it doesn't become required.  The current non-use
> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
> >>>
> >>>
> >> Having built and packaged linux from scratch using the rpm package
> >> manager, I came to find that if one is building packages to be used on
> >> multiple machines, one needs to build each package in a chroot
> >> environment or the package could inherit things from the parent not
> >> found in the target machine.  Here by making the package unusable.
> > Hello. You shouldn't have any difficulty accomplishing your goal
> > by simply setting up a jail, and using portmaster within that jail(8).
> > portmaster really doesn't care where it's run. So long as it has
> > everything it needs to accomplish it's job(s). :-)
> >
>  From my point of view, jails are overkill. Chroot should be enough and 
> it would be nice if portmaster starts building in clean environment.

Just dropping privileges to a dedicated user for building would be a big step, 
but that's more a port feature (openbsd's ports do that, if I'm not wrong).



-- 
Matthieu Volat 



pgp61YY2k5YcB.pgp
Description: OpenPGP digital signature

Re: The future of portmaster

[abi]

17.02.2017 00:22, Chris H пишет:

On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot  wrote


On 02/16/17 15:40, George Mitchell wrote:

On 02/16/17 15:33, Baho Utot wrote:


On 02/16/17 14:01, Lowell Gilbert wrote:

Baho Utot  writes:


On 02/16/17 06:08, Luca Pizzamiglio wrote:

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.

If you can have it build in a clean chroot or jail then you'll get my
attention

What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.


Using chroot or jails to build each individual package
[...]

While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George



Having built and packaged linux from scratch using the rpm package
manager, I came to find that if one is building packages to be used on
multiple machines, one needs to build each package in a chroot
environment or the package could inherit things from the parent not
found in the target machine.  Here by making the package unusable.

Hello. You shouldn't have any difficulty accomplishing your goal
by simply setting up a jail, and using portmaster within that jail(8).
portmaster really doesn't care where it's run. So long as it has
everything it needs to accomplish it's job(s). :-)

From my point of view, jails are overkill. Chroot should be enough and 
it would be nice if portmaster starts building in clean environment.

___
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: The future of portmaster

[Baho Utot]

On 02/16/17 17:49, Johan Hendriks wrote:



Op 16/02/2017 om 23:04 schreef Baho Utot:



On 02/16/17 16:48, Mark Linimon wrote:

On Thu, Feb 16, 2017 at 04:36:24PM -0500, Baho Utot wrote:

Oh no I am now banned as I use synth, whoa is me.


This is overstating the matter.

May we restrict ourselves to the technical problems/features of the
various port maintainence tools, please? :-/



See I knew it, the police are out in forceYou'ns  got John and now
it looks like I am going to have to go on the run.



No need to run, no police, just talk about portmaster and tell what can
be done to make it better. The thread is named The future of portmaster
after all.


One can never be too sure,Oh wait is see some men in black coming my 
way now.  Got to run.  Don't tell them I have been here so, I have some 
time to getway.




___
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: The future of portmaster

[Johan Hendriks]

Op 16/02/2017 om 23:04 schreef Baho Utot:
>
>
> On 02/16/17 16:48, Mark Linimon wrote:
>> On Thu, Feb 16, 2017 at 04:36:24PM -0500, Baho Utot wrote:
>>> Oh no I am now banned as I use synth, whoa is me.
>>
>> This is overstating the matter.
>>
>> May we restrict ourselves to the technical problems/features of the
>> various port maintainence tools, please? :-/
>>
>
> See I knew it, the police are out in forceYou'ns  got John and now
> it looks like I am going to have to go on the run.
No need to run, no police, just talk about portmaster and tell what can
be done to make it better. The thread is named The future of portmaster
after all.
If synth is better, maybe someone will get an idea for portmaster so
that it can learn from the synth way of doing things.
No need to let the marino issue come back in every thread on the mailing
lists.
I think that everybody by now knows what is going on and the people
involved feel bad enough about the whole situation already.
I hope they can settle things in a way that is in the best intrest for
FreeBSD and DragonFlyBSD.

Nice to see some work is done on portmaster. Thank you all for that.

regards
Johan
>
> ___
> 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: The future of portmaster

[Baho Utot]

On 02/16/17 16:48, Mark Linimon wrote:

On Thu, Feb 16, 2017 at 04:36:24PM -0500, Baho Utot wrote:

Oh no I am now banned as I use synth, whoa is me.


This is overstating the matter.

May we restrict ourselves to the technical problems/features of the
various port maintainence tools, please? :-/



See I knew it, the police are out in forceYou'ns  got John and now 
it looks like I am going to have to go on the run.

___
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: The future of portmaster

[Mark Linimon]

On Thu, Feb 16, 2017 at 04:36:24PM -0500, Baho Utot wrote:
> Oh no I am now banned as I use synth, whoa is me.

This is overstating the matter.

May we restrict ourselves to the technical problems/features of the
various port maintainence tools, please? :-/

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: The future of portmaster

[Chris H]

On Thu, 16 Feb 2017 16:36:24 -0500 Baho Utot  wrote

> On 02/16/17 16:22, Chris H wrote:
> > On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot 
> > wrote >
> >> On 02/16/17 15:40, George Mitchell wrote:
> >>> On 02/16/17 15:33, Baho Utot wrote:
> 
> 
>  On 02/16/17 14:01, Lowell Gilbert wrote:
> > Baho Utot  writes:
> >
> >> On 02/16/17 06:08, Luca Pizzamiglio wrote:
> >>> I'm looking for constructive critics, feedbacks, anything that can
> >>> help me to make portmaster an actively maintained and used tool.
> >>
> >> If you can have it build in a clean chroot or jail then you'll get my
> >> attention
> >
> > What kind of special support?
> >
> > I use it with a chroot that mounts /usr/ports (and src) read-only, and
> > aside from the initial base system install, it took about fifteen
> > minutes to set up.
> >
> 
>  Using chroot or jails to build each individual package
>  [...]
> >>>
> >>> While I understand the interest in chroot/jails as an optional
> >>> feature, I hope it doesn't become required.  The current non-use
> >>> of chroot/jails is, for me, a feature -- not a bug.-- George
> >>>
> >>>
> >>
> >> Having built and packaged linux from scratch using the rpm package
> >> manager, I came to find that if one is building packages to be used on
> >> multiple machines, one needs to build each package in a chroot
> >> environment or the package could inherit things from the parent not
> >> found in the target machine.  Here by making the package unusable.
> >
> > Hello. You shouldn't have any difficulty accomplishing your goal
> > by simply setting up a jail, and using portmaster within that jail(8).
> > portmaster really doesn't care where it's run. So long as it has
> > everything it needs to accomplish it's job(s). :-)
> >
> 
> Hello. Having portmaster do that ( automatically/or by default ) is 
> better as in I wont have to do that just run the damn tool with a list 
> of packages.  Just like synth does.   Oh no I am now banned as I use 
> synth, whoa is me.
Heh. Actually I usually use *traditional* jails to make my repo's.
But when I don't, I *too* prefer synth. Nothing political. I just
like it better -- it's faster, and less fuss.

--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: The future of portmaster

[Baho Utot]

On 02/16/17 16:22, Chris H wrote:

On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot  wrote


On 02/16/17 15:40, George Mitchell wrote:

On 02/16/17 15:33, Baho Utot wrote:



On 02/16/17 14:01, Lowell Gilbert wrote:

Baho Utot  writes:


On 02/16/17 06:08, Luca Pizzamiglio wrote:

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.


If you can have it build in a clean chroot or jail then you'll get my
attention


What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.



Using chroot or jails to build each individual package
[...]


While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George




Having built and packaged linux from scratch using the rpm package
manager, I came to find that if one is building packages to be used on
multiple machines, one needs to build each package in a chroot
environment or the package could inherit things from the parent not
found in the target machine.  Here by making the package unusable.


Hello. You shouldn't have any difficulty accomplishing your goal
by simply setting up a jail, and using portmaster within that jail(8).
portmaster really doesn't care where it's run. So long as it has
everything it needs to accomplish it's job(s). :-)



Hello. Having portmaster do that ( automatically/or by default ) is 
better as in I wont have to do that just run the damn tool with a list 
of packages.  Just like synth does.   Oh no I am now banned as I use 
synth, whoa is me.




___
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: The future of portmaster

[Chris H]

On Thu, 16 Feb 2017 15:48:57 -0500 Baho Utot  wrote

> On 02/16/17 15:40, George Mitchell wrote:
> > On 02/16/17 15:33, Baho Utot wrote:
> >>
> >>
> >> On 02/16/17 14:01, Lowell Gilbert wrote:
> >>> Baho Utot  writes:
> >>>
>  On 02/16/17 06:08, Luca Pizzamiglio wrote:
> > I'm looking for constructive critics, feedbacks, anything that can
> > help me to make portmaster an actively maintained and used tool.
> 
>  If you can have it build in a clean chroot or jail then you'll get my
>  attention
> >>>
> >>> What kind of special support?
> >>>
> >>> I use it with a chroot that mounts /usr/ports (and src) read-only, and
> >>> aside from the initial base system install, it took about fifteen
> >>> minutes to set up.
> >>>
> >>
> >> Using chroot or jails to build each individual package
> >> [...]
> >
> > While I understand the interest in chroot/jails as an optional
> > feature, I hope it doesn't become required.  The current non-use
> > of chroot/jails is, for me, a feature -- not a bug.-- George
> >
> >
> 
> Having built and packaged linux from scratch using the rpm package 
> manager, I came to find that if one is building packages to be used on 
> multiple machines, one needs to build each package in a chroot 
> environment or the package could inherit things from the parent not 
> found in the target machine.  Here by making the package unusable.

Hello. You shouldn't have any difficulty accomplishing your goal
by simply setting up a jail, and using portmaster within that jail(8).
portmaster really doesn't care where it's run. So long as it has
everything it needs to accomplish it's job(s). :-)

HTH

--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: The future of portmaster

[Daryl Richards]

While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George




Having built and packaged linux from scratch using the rpm package 
manager, I came to find that if one is building packages to be used on 
multiple machines, one needs to build each package in a chroot 
environment or the package could inherit things from the parent not 
found in the target machine.  Here by making the package unusable.


For those of use who have a half-dozen machines, all with differing 
options, having a central build machine doesn't make a lot of sense. 
Have a tool like portmaster, for ease of local building and upgrading of 
ports, is very useful.


Just my 2c worth. I'm glad to see people believing there is still a 
place for a tool like this.


___
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: The future of portmaster

[Baho Utot]

On 02/16/17 15:40, George Mitchell wrote:

On 02/16/17 15:33, Baho Utot wrote:



On 02/16/17 14:01, Lowell Gilbert wrote:

Baho Utot  writes:


On 02/16/17 06:08, Luca Pizzamiglio wrote:

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.


If you can have it build in a clean chroot or jail then you'll get my
attention


What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.



Using chroot or jails to build each individual package
[...]


While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George




Having built and packaged linux from scratch using the rpm package 
manager, I came to find that if one is building packages to be used on 
multiple machines, one needs to build each package in a chroot 
environment or the package could inherit things from the parent not 
found in the target machine.  Here by making the package unusable.

___
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: The future of portmaster

[George Mitchell]

On 02/16/17 15:33, Baho Utot wrote:
> 
> 
> On 02/16/17 14:01, Lowell Gilbert wrote:
>> Baho Utot  writes:
>>
>>> On 02/16/17 06:08, Luca Pizzamiglio wrote:
 I'm looking for constructive critics, feedbacks, anything that can
 help me to make portmaster an actively maintained and used tool.
>>>
>>> If you can have it build in a clean chroot or jail then you'll get my
>>> attention
>>
>> What kind of special support?
>>
>> I use it with a chroot that mounts /usr/ports (and src) read-only, and
>> aside from the initial base system install, it took about fifteen
>> minutes to set up.
>>
> 
> Using chroot or jails to build each individual package
> [...]

While I understand the interest in chroot/jails as an optional
feature, I hope it doesn't become required.  The current non-use
of chroot/jails is, for me, a feature -- not a bug.-- George




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[Baho Utot]

On 02/16/17 14:01, Lowell Gilbert wrote:

Baho Utot  writes:


On 02/16/17 06:08, Luca Pizzamiglio wrote:

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.


If you can have it build in a clean chroot or jail then you'll get my
attention


What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.



Using chroot or jails to build each individual package
___
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: The future of portmaster

[Lowell Gilbert]

Baho Utot  writes:

> On 02/16/17 06:08, Luca Pizzamiglio wrote:
>> I'm looking for constructive critics, feedbacks, anything that can
>> help me to make portmaster an actively maintained and used tool.
>
> If you can have it build in a clean chroot or jail then you'll get my
> attention

What kind of special support?

I use it with a chroot that mounts /usr/ports (and src) read-only, and
aside from the initial base system install, it took about fifteen
minutes to set up.
___
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: The future of portmaster

[Mark Linimon]

I am glad to see that someone is taking on the work.  Thanks.

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: The future of portmaster

[George Mitchell]

On 02/16/17 06:08, Luca Pizzamiglio wrote:
> Hi all,
> 
> portmaster, a tool used/loved/hated, is almost in abandoned state.
> I'm a portmaster user, because, in some cases, it fits my needs.
> In other cases, I use other tools, like poudriere or synth, that are
> really great.
> I don't want to open a discussion here about what it's better, but the
> truth is, that I use portmaster and it's not maintained.
> So I decided to spend some time to look at it and to work on it.
> 
> I forked it and I start some work.
> The plan is:
> - remove obsolete features, like the -PP option
> - remove pkg_* support (even if someone could be against it), forcing
> the usage of pkg
> - prepare the support of new features like FLAVORS and subpackages
> - adding a new ports, called portmaster-devel, for the new version
> 
> I did a branch on github working of the first two points
> (https://github.com/pizzamig/portmaster/tree/remove_oldpkg)
> 
> I'm looking for constructive critics, feedbacks, anything that can
> help me to make portmaster an actively maintained and used tool.
> 
> Thanks in advance
> 
> Best regards,
> pizzamig
> [...]
Thank you!  poudriere regularly runs out of resources on my ten
year old machine, and I've been disinclined to try synth so far
(though I guess it may come to that soon).  Up to now, portmaster
has worked fine for me (bearing in mind I have a machine dedicated
to ports building and the world doesn't end if I break it and have
to clean up and start over again on occasion).   -- George




signature.asc
Description: OpenPGP digital signature

Re: The future of portmaster

[Warren Block]

On Thu, 16 Feb 2017, Luca Pizzamiglio wrote:


Hi all,

portmaster, a tool used/loved/hated, is almost in abandoned state.
I'm a portmaster user, because, in some cases, it fits my needs.
In other cases, I use other tools, like poudriere or synth, that are
really great.
I don't want to open a discussion here about what it's better, but the
truth is, that I use portmaster and it's not maintained.
So I decided to spend some time to look at it and to work on it.

I forked it and I start some work.
The plan is:
- remove obsolete features, like the -PP option
- remove pkg_* support (even if someone could be against it), forcing
the usage of pkg
- prepare the support of new features like FLAVORS and subpackages
- adding a new ports, called portmaster-devel, for the new version

I did a branch on github working of the first two points
(https://github.com/pizzamig/portmaster/tree/remove_oldpkg)

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.


Thank you for working on this.  The most recent commit added my patch to 
save the command to restart the build when an individual port build 
fails.  It shows "portmaster  ...".  Showing the actual flags 
given would be useful.


A less trivial change would be to show the ports to be built in 
dependency order rather than sorted.


Thanks!
___
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: The future of portmaster

[Baho Utot]

On 02/16/17 06:08, Luca Pizzamiglio wrote:

Hi all,

portmaster, a tool used/loved/hated, is almost in abandoned state.
I'm a portmaster user, because, in some cases, it fits my needs.
In other cases, I use other tools, like poudriere or synth, that are
really great.
I don't want to open a discussion here about what it's better, but the
truth is, that I use portmaster and it's not maintained.
So I decided to spend some time to look at it and to work on it.

I forked it and I start some work.
The plan is:
- remove obsolete features, like the -PP option
- remove pkg_* support (even if someone could be against it), forcing
the usage of pkg
- prepare the support of new features like FLAVORS and subpackages
- adding a new ports, called portmaster-devel, for the new version

I did a branch on github working of the first two points
(https://github.com/pizzamig/portmaster/tree/remove_oldpkg)

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.

Thanks in advance

Best regards,
pizzamig

PS: I won't start a port/pkg tool war, my opinion is that the world is
big enough to have poudriere, synth, portmaster, portupgrade and
whatever tool you will write to handle/build any ports package in the
way that you prefer.
___
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"




If you can have it build in a clean chroot or jail then you'll get my 
attention

___
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: The future of portmaster

[David Wolfskill]

On Thu, Feb 16, 2017 at 12:08:52PM +0100, Luca Pizzamiglio wrote:
> Hi all,
> 
> portmaster, a tool used/loved/hated, is almost in abandoned state.
> ...
> So I decided to spend some time to look at it and to work on it.
> 

Thank you!

(I'll take a look at your work later; I'm in the middle of buildworld &
friends now.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

The future of portmaster

[Luca Pizzamiglio]

Hi all,

portmaster, a tool used/loved/hated, is almost in abandoned state.
I'm a portmaster user, because, in some cases, it fits my needs.
In other cases, I use other tools, like poudriere or synth, that are
really great.
I don't want to open a discussion here about what it's better, but the
truth is, that I use portmaster and it's not maintained.
So I decided to spend some time to look at it and to work on it.

I forked it and I start some work.
The plan is:
- remove obsolete features, like the -PP option
- remove pkg_* support (even if someone could be against it), forcing
the usage of pkg
- prepare the support of new features like FLAVORS and subpackages
- adding a new ports, called portmaster-devel, for the new version

I did a branch on github working of the first two points
(https://github.com/pizzamig/portmaster/tree/remove_oldpkg)

I'm looking for constructive critics, feedbacks, anything that can
help me to make portmaster an actively maintained and used tool.

Thanks in advance

Best regards,
pizzamig

PS: I won't start a port/pkg tool war, my opinion is that the world is
big enough to have poudriere, synth, portmaster, portupgrade and
whatever tool you will write to handle/build any ports package in the
way that you prefer.
___
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"