FreeBSD ports you maintain which are out of date

2017-02-17 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
biology/tinker  | 7.1.3   | 8.1.2
+-+
devel/ocaml-ipaddr  | 2.6.1   | 2.7.2
+-+
devel/py-setuptools-git | 1.1 | 1.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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

2017-02-17 Thread 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: Ports search last database update 2016-01-01

2017-02-17 Thread Wolfram Schneider 
On 7 February 2017 at 08:44, Niklas Blomdalen | LOP via freebsd-doc
 wrote:
> Hi.
> I just thought you might want to check the ports db sync
> https://www.freebsd.org/cgi/ports.cgi
> Last database update: 2016-01-01 06:08:21 UTC
>
> Seems like something is stuck somewhere.
> It seems to be a fresh copy though, but the date might not reflect reality.

Hi Niklas,

thanks for your report. The issue is fixed now.

-Wolfram

-- 
Wolfram Schneider  http://wolfram.schneider.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

2017-02-17 Thread 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

2017-02-17 Thread 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

2017-02-17 Thread 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: Status of synth following expulsion of John Marino?

2017-02-17 Thread Shane Ambler 

On 16/02/2017 14:20, Thomas Mueller wrote:



For every build - /usr/local/etc/poudriere.d/make.conf



OPTIONS_SET= OPTIMIZED_CFLAGS SIMD PGSQL IPV6 editors_vim_SET=
CSCOPE X11 GTK3 PYTHON



You can also get more specific by using -



/usr/local/etc/poudriere.d/-make.conf
/usr/local/etc/poudriere.d/-make.conf
/usr/local/etc/poudriere.d/-make.conf
/usr/local/etc/poudriere.d/--make.conf
/usr/local/etc/poudriere.d/--make.conf
/usr/local/etc/poudriere.d/---make.conf




Shane Ambler


Is there any way to do this options preconfiguring not using
poudriere?

One good thing about NetBSD pkgsrc, also Gentoo portage, is being
able to set options by package or for all packages in /etc/make.conf
or mk.conf .

Is there a good way to do this in FreeBSD prior to running synth?



Any options you setup for poudriere work just the same when placed in
/etc/make.conf - poudriere copies the above files into /etc/make.conf in
the build environment.

You can define BATCH in your make.conf to stop config dialogs
- poudriere adds BATCH=yes to the make.conf of each build jail.

synth also has it's own files in /usr/local/etc/synth that it will use.
See man synth


--
FreeBSD - the place to B...Software Developing

Shane Ambler
___
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

2017-02-17 Thread 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

2017-02-17 Thread 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

2017-02-17 Thread 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