FreeBSD ports you maintain which are out of date

2016-12-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
+-+
editors/vile| 9.8q| 9.8s
+-+
editors/xvile   | 9.8q| 9.8s
+-+
net-mgmt/mk-livestatus  | 1.2.8p13| 1.2.8p14
+-+


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 ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/18/2016 00:43, Greg 'groggy' Lehey wrote:

On Saturday, 17 December 2016 at 20:16:12 -0600, John Marino wrote:

On 12/17/2016 19:35, Peter Jeremy wrote:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - not 
found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.

Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
to see why you are so insistant on replacing it with something that doesn't
work at all.


Real smooth there, Slick.


Sarcasm might get you somewhere, but I'm not sure you want to be
there.


He was trolling.  You know it. I know it.  Everyone that read it knows it.




It's been mentioned several times in this thread alone that Ada is
only available for i386 and amd64.  I think you already knew that
and thus this is a pure troll.


I think Peter has highlighted a significant weakness.  A tool that
doesn't work on all platforms is hardly a replacement for a core tool
that does.


A) Portmaster is not a "core" tool.  That has been clearly defined.  It 
is not official and references at imply that are supposed to be scrubbed 
from the documentation.


B) This whole "replacement" thing has been warped.  Poudriere by itself 
"replaces" portmaster.  It meets the criteria of "no dependencies / all 
platforms".


C) The idea was that people that use portmaster had newer tools.

D) Synth doesn't even "replace" poudriere.  It performs better and can 
just about everythere poudriere can and some things it can't, but I've 
never recommended that a poudriere user should switch.


The whole "see, it's not a replacement, you lose" tactic is weak and 
transparent.  Nobody ever said that.  what was said:


1) portmaster is not maintained (true)
2) portmaster's dirty build method is inferior to clean environment 
builds (true)

3) There is better and official alternative (true)
4) There's a second, even more effective alternative for x86 platforms 
(true)

5) portmaster should come with a big fat warning (subjective)

So poudriere doesn't have this "weakness" and synth only has it because 
these 2nd tier platforms are popular enough to warrant bringing the Ada 
compiler over to them.  Is it possible to port the ada frontend to 
armv6/v7?  Of course, I've already done it, see lang/gnatdroid*. 
However, it's questionable to try to build huge packages natively on 
armv6/7.


You can't claim portmaster is the only and therefore best option for 
second tier platforms.  It's untrue.  Saying it runs where synth isn't 
available doesn't justify keeping portmaster at an exulted status.  You 
cannot dismiss poudriere like that.


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread Greg 'groggy' Lehey 
On Saturday, 17 December 2016 at 20:16:12 -0600, John Marino wrote:
> On 12/17/2016 19:35, Peter Jeremy wrote:
>> $ cd /usr/ports/ports-mgmt/synth/ && make
>> [ about an hour of grinding away elided ]
>> ===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - 
>> not found
>> ===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.
>>
>> Overall, a total failure.
>>
>> OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
>> to see why you are so insistant on replacing it with something that doesn't
>> work at all.
>
> Real smooth there, Slick.

Sarcasm might get you somewhere, but I'm not sure you want to be
there.

> It's been mentioned several times in this thread alone that Ada is
> only available for i386 and amd64.  I think you already knew that
> and thus this is a pure troll.

I think Peter has highlighted a significant weakness.  A tool that
doesn't work on all platforms is hardly a replacement for a core tool
that does.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 19:35, Peter Jeremy wrote:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - not 
found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.

Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
to see why you are so insistant on replacing it with something that doesn't
work at all.



Real smooth there, Slick.

It's been mentioned several times in this thread alone that Ada is only 
available for i386 and amd64.  I think you already knew that and thus 
this is a pure troll.


Use poudriere for non-x86 platforms.  armv6 packages are built with 
poudriere + QEMU, but I suspect you already knew this as well.


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread Peter Jeremy 
Since you insist it's perfect, I thought I'd try synth...

On 2016-Dec-16 09:06:30 -0600, John Marino  wrote:
>Starting with a clean system:
>1) install synth from binary package from official freebsd builder (a 
>single package)

I don't understand why I need to install synth in order to build synth but
anyway:
$ sudo pkg install synth
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
pkg: No packages available to install matching 'synth' have been found in the 
repositories
$

So I'll try to build it the old fashioned way, having downloaded nearly
100MB of sources I didn't already have:

$ cd /usr/ports/ports-mgmt/synth/ && make
[ about an hour of grinding away elided ]
===>   ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - not 
found
===>  gcc6-aux-20160822 is only for amd64 i386, while you are running armv6.

Overall, a total failure.

OTOH, portmaster installs in a minute or so and runs perfectly well.  I fail
to see why you are so insistant on replacing it with something that doesn't
work at all.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

2016-12-17 Thread Alphons van Werven 
John Marino wrote:

> maybe you could open one final PR and provide a patch that does this?

Fair enough, will do.

Fonz

-- 
A.J. "Fonz" van Werven 
Notice: this e-mail address wil expire on Sat 24 Dec 2016.


signature.asc
Description: PGP signature

Re: Dropping enigmail support from enigmail

2016-12-17 Thread Jan Beich 
Martin Birgmeier  writes:

> After upgrading to thunderbird-45.5.1_6 I noticed that enigmail (and
> lightning) support were gone from thunderbird. I tried to find a
> replacement package until I read the svn log message:

Lightning had 2 copies, only one of those was removed. For Enigmail see
/usr/ports/UPDATING from 20161216.

> I think a decision to remove such an essential component should not be
> taken so lightly, especially when the actual port version (45.5.1) has
> not even changed.

Why the version should change? Enigmail isn't part of Thunderbird distribution
but just one of third-party extensions you can find on addons.mozilla.org.
For historic reasons it was bundled with the port but the requirment is gone.

ENIGMAIL option was unmaintained beyond updates which were irregular.
And it was bound to get in the way if anyone attempted to refactor the
current maintenance nightmare gecko@ is in.
___
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"

Dropping enigmail support from enigmail

2016-12-17 Thread Martin Birgmeier 
After upgrading to thunderbird-45.5.1_6 I noticed that enigmail (and
lightning) support were gone from thunderbird. I tried to find a
replacement package until I read the svn log message:

gecko: drop ENIGMAIL, LIGHTNING to simplify updates
ENIGMAIL can still return as www/xpi-enigmail but, alas, xpi-* ports and
their framework are mostly unmaintained.

So this means that after a simple PORTREVISION change I cannot send,
receive, or reread encrypted mails any more.

I think a decision to remove such an essential component should not be
taken so lightly, especially when the actual port version (45.5.1) has
not even changed.

What is being planned to remedy this unfortunate situation?

-- Martin


___
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 ports collection has some serious issues

2016-12-17 Thread Michael Gmelin 


> On 17 Dec 2016, at 20:47, Alphons van Werven  wrote:
> 
> Michael Gmelin wrote:
> 
>> Maybe you could elaborate a bit more what you find so annoying about
>> running "poudriere testport origin" before doing "svn commit" that you
>> are willing to drop port maintainership over it?
> 
> Sure. In this case it's the precedent that bugs me.
> 
> Needless to say, not being a committer myself, whether/that said folks are
> required to use Poudriere and/or Synth for their QA checking is ipso facto
> none of my concern. However, I'm pretty sure I know what comes next. When
> maintainers need to provide build/QA logs with their PRs (which I think in
> many cases makes perfect sense to request, BTW) soon enough Portupgrade or
> Portmaster logs, Portlint output, output of explicit
>  # make check-foo && make bar-qa && make love && make install
> and such will cease to suffice and those logs will be going to have to be
> Poudriere and/or Synth logs specifically. In other words: I suspect it
> won't be long before port maintainership will de facto force maintainers
> to install, learn and use Poudriere and/or Synth. And it just so happens
> that for me the former in particular is a definite no go for flight.
> 
> To put things into perspective, I do feel compelled to point out that this
> is merely the straw that broke the proverbial camel's back. Or the spark
> that ignited the gunpowder, if one happens to know what poudriere actually
> means. I've been a FreeBSD stalwart since the turn of the century (if not
> slightly earlier) and for the most part it has been wonderful. But ever
> since some time during the 9.X era I started to pick up signs that the
> FreeBSD project as a whole is moving into a direction that troubles me--in
> some cases deeply indeed. Particularly during the last few months I found
> myself increasingly strongly contemplating moving away from FreeBSD
> altogether. And that is exactly what I've now decided to do.
> 
> There's nothing overly dramatic about that; it's a simple observation that
> too many things involving the FreeBSD project in general are going in what
> I consider undesirable directions, leading to the pragmatic conclusion
> that, the past notwithstanding, FreeBSD is unfortunately no longer the
> right operating system for me, neither personally nor professionally.
> 
> I'll assume the above was sufficiently elaborate.
> 

It was quite elaborate, but didn't really answer the question - it managed to 
explain your emotions though, maybe that was more important anyway.

Attaching poudriere logs has been best practice for years now and I (using 
FreeBSD since the mid-90s) adapted quickly, as it made perfect sense to me and 
getting started with poudriere just took a couple of minutes. If anything, the 
situation got better this year, as we have a second option (synth) available 
now.

Anyway, it's sad to see you leave, thanks for all your contributions, I've been 
using some of your ports for years.

-m
___
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 ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 13:47, Alphons van Werven wrote:

Needless to say, not being a committer myself, whether/that said folks are
required to use Poudriere and/or Synth for their QA checking is ipso facto
none of my concern. However, I'm pretty sure I know what comes next. When
maintainers need to provide build/QA logs with their PRs (which I think in
many cases makes perfect sense to request, BTW) soon enough Portupgrade or
Portmaster logs, Portlint output, output of explicit
  # make check-foo && make bar-qa && make love && make install
and such will cease to suffice and those logs will be going to have to be
Poudriere and/or Synth logs specifically. In other words: I suspect it
won't be long before port maintainership will de facto force maintainers
to install, learn and use Poudriere and/or Synth. And it just so happens
that for me the former in particular is a definite no go for flight.


portmaster and portupgrade logs have not been sufficient in years.
It is quite possible to pass building in those and fail miserably in 
reliable environments such as poudriere.  Since they are 100% 
untrustworthy, no, they aren't acceptable.  I mean, they are better than 
zero testing effort at all, but barely.





To put things into perspective, I do feel compelled to point out that this
is merely the straw that broke the proverbial camel's back. Or the spark
that ignited the gunpowder, if one happens to know what poudriere actually
means. I've been a FreeBSD stalwart since the turn of the century (if not
slightly earlier) and for the most part it has been wonderful. But ever
since some time during the 9.X era I started to pick up signs that the
FreeBSD project as a whole is moving into a direction that troubles me--in
some cases deeply indeed. Particularly during the last few months I found
myself increasingly strongly contemplating moving away from FreeBSD
altogether. And that is exactly what I've now decided to do.

There's nothing overly dramatic about that; it's a simple observation that
too many things involving the FreeBSD project in general are going in what
I consider undesirable directions, leading to the pragmatic conclusion
that, the past notwithstanding, FreeBSD is unfortunately no longer the
right operating system for me, neither personally nor professionally.

I'll assume the above was sufficiently elaborate.


well, sorry to see you go.
Since reverting your name on that many ports is quite a bit of work, 
maybe you could open one final PR and provide a patch that does this?


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread Alphons van Werven 
Michael Gmelin wrote:

> Maybe you could elaborate a bit more what you find so annoying about
> running "poudriere testport origin" before doing "svn commit" that you
> are willing to drop port maintainership over it?

Sure. In this case it's the precedent that bugs me.

Needless to say, not being a committer myself, whether/that said folks are
required to use Poudriere and/or Synth for their QA checking is ipso facto
none of my concern. However, I'm pretty sure I know what comes next. When
maintainers need to provide build/QA logs with their PRs (which I think in
many cases makes perfect sense to request, BTW) soon enough Portupgrade or
Portmaster logs, Portlint output, output of explicit
  # make check-foo && make bar-qa && make love && make install
and such will cease to suffice and those logs will be going to have to be
Poudriere and/or Synth logs specifically. In other words: I suspect it
won't be long before port maintainership will de facto force maintainers
to install, learn and use Poudriere and/or Synth. And it just so happens
that for me the former in particular is a definite no go for flight.

To put things into perspective, I do feel compelled to point out that this
is merely the straw that broke the proverbial camel's back. Or the spark
that ignited the gunpowder, if one happens to know what poudriere actually
means. I've been a FreeBSD stalwart since the turn of the century (if not
slightly earlier) and for the most part it has been wonderful. But ever
since some time during the 9.X era I started to pick up signs that the
FreeBSD project as a whole is moving into a direction that troubles me--in
some cases deeply indeed. Particularly during the last few months I found
myself increasingly strongly contemplating moving away from FreeBSD
altogether. And that is exactly what I've now decided to do.

There's nothing overly dramatic about that; it's a simple observation that
too many things involving the FreeBSD project in general are going in what
I consider undesirable directions, leading to the pragmatic conclusion
that, the past notwithstanding, FreeBSD is unfortunately no longer the
right operating system for me, neither personally nor professionally.

I'll assume the above was sufficiently elaborate.

Regards,

Fonz

-- 
A.J. "Fonz" van Werven 
Notice: this e-mail address wil expire on Sat 24 Dec 2016.


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 13:35, Mark Linimon wrote:

This is the sixth "top of thread" post.  Could you please arrange to stop
breaking email threading?  Thanks.

mcl



I have to assume you're talking to me.
Mark:
1) I am not subscribed to the mail list
2) FreeBSD chooses not to store the raw email content like it does for 
svn commits.


Thus I have no way to "continue" a thread that didn't CC me.

Now, given those two facts, what *EXACTLY* do you suggest I do differently?

Right now you are attacking me for something that's not my fault.  It's 
FreeBSD's fault if anything.  I don't care if the consequence is a 
broken thread since FreeBSD has the ability to make it better.


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread Mark Linimon 
This is the sixth "top of thread" post.  Could you please arrange to stop
breaking email threading?  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 ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 12:34, abi wrote:



2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't
know what else will be pulled to my system after port tree update.


which of course is a false statement.
If you set port options which then change, Synth will stop and tell
you to reconfigure or remove the saved port options.


Not at all. For example, let's assume I go recommended way and have
options for ports with not default settings. Let's say, I have perl with
default options (no OPTIONS file). Let's say port maintainer adds new
option, [NSA Backdoor]
Perl will be silently compiled with that option, right?


Yes.  If you don't explicitly save the options then Synth has no way to 
detect a change in options.



This is not paranoia, here is example from real world - I rebuilded one port and
noticed new option - [USE GCC] with default On. I really don't want that
gnu beast in my system, so I investigated the problem and suggested
patch to compile port under clang. Everyone happy. We can search PR
database if you don't believe me.
If I was synth user, I've ended with gcc pulled.


If your view of the world means that any or all ports maintainers are 
out to get you, then yes, I see your problem.


There are ways to recursively set every possible option though.  You can 
easily write a script to iterate your build list and recursively check 
every option using the standard ports framework.


If you did that, then synth would detect every option change and stop.






2.2 If I make option files for all ports, synth fails to rebuild
repository if port and it's options are out of sync.


yes, of course.  If you give it impossible instructions, it will stop
and ask you to fix them.  Any reasonable person would want to be
informed when the options are incorrect.  Did you also notice that
extended use of portmaster resulted in dozens of obsolete options
files that you weren't aware of?  So your criticism here is that you
think Synth should just ignore these bad configurations?

No, I didn't notece obsolete options. Maybe my /var/db/ports is a
complete mess and I should cry in tears. but when portmaster encounters
new options it invokes dialog4ports and let me fix the problem. If this
leaves some staled OPTIONS file, I'd say it's portmaster bug, not design
feature. We all know that portmaster is in rather poor shape.


The detection of changed options by ports framework doesn't always work. 
 It definitely doesn't work if portmaster is controlling it.  You 
shouldn't rely on this.




First of all, synth ignores /etc/make.conf completely. Yes, we


As does poudriere, as it was designed to do.  As it should do.


definitely need another place to keep global make options, however
DEFAULT_VERSIONS suggestion is a bad advice here.
Here is example: recently ports framework deprecated perl 5.20 and
switched to 5.24
portmaster users should recompile all ports depended on perl (from my
point of view this is done not very reliable), but when it comes to new
perl, portmaster will invoke dialog4ports.
synth user with non-default perl options will receive new perl with
default one. I hit this very problem during my synth test when I noticed
pgadmin3 liked to postgresql93-client and added DEFAULT_VERSIONS to 96.


synth will rebuild everything that changes as a result of change to 
[profile]-make.conf as does poudriere.  It deletes the obsoleted 
packages first then rebuilds everything that's missing.  It works.


If you use "synth status" to give it a build list, of course it's also 
going to keep building the old perl because you told it to.  That's just 
a convenience command.  If you want to be exact, you maintain a discrete 
build list of the prime ports.  When in doubt, you can always remove all 
and reinstall the prime list after the repository is brought up to 
speed.  That's not necessarily done often, but it is guaranteed to 
always work.




I see how synth can be used in pkg framework, I even agree that synth is
poudriere done right and I feel I will use synth test feature for ports
I maintain, what I fail to see, how I can use it to keep my laptop
updated. I'm not asking for pony here, the examples I provided (if true)
lead to overcomplexity maintaining packages up to date.


I guess it just takes more experience.  It's definitely not more complex 
than portmaster.  I would say it's simpler.


Plus the fact that portmaster can only build serially while both synth 
and poudriere build in parallel is a huge advantage to any single system 
user.


John


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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"

graphics/ocropus - new repository?

2016-12-17 Thread Torfinn Ingolfsen 
FWIW, it looks like https://github.com/tmbdev/ocropy is a (new)
repository for ocropus source code.
HTH
-- 
Regards,
Torfinn Ingolfsen
___
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 ports collection has some serious issues

2016-12-17 Thread abi 



2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't
know what else will be pulled to my system after port tree update.


which of course is a false statement.
If you set port options which then change, Synth will stop and tell 
you to reconfigure or remove the saved port options.


Not at all. For example, let's assume I go recommended way and have 
options for ports with not default settings. Let's say, I have perl with 
default options (no OPTIONS file). Let's say port maintainer adds new 
option, [NSA Backdoor]
Perl will be silently compiled with that option, right? This is not 
paranoia, here is example from real world - I rebuilded one port and 
noticed new option - [USE GCC] with default On. I really don't want that 
gnu beast in my system, so I investigated the problem and suggested 
patch to compile port under clang. Everyone happy. We can search PR 
database if you don't believe me.

If I was synth user, I've ended with gcc pulled.




2.2 If I make option files for all ports, synth fails to rebuild
repository if port and it's options are out of sync.


yes, of course.  If you give it impossible instructions, it will stop 
and ask you to fix them.  Any reasonable person would want to be 
informed when the options are incorrect.  Did you also notice that 
extended use of portmaster resulted in dozens of obsolete options 
files that you weren't aware of?  So your criticism here is that you 
think Synth should just ignore these bad configurations?
No, I didn't notece obsolete options. Maybe my /var/db/ports is a 
complete mess and I should cry in tears. but when portmaster encounters 
new options it invokes dialog4ports and let me fix the problem. If this 
leaves some staled OPTIONS file, I'd say it's portmaster bug, not design 
feature. We all know that portmaster is in rather poor shape.



2.3 When port infrastructure switch to newer default version I must be
aware that this change occur and set damn options for new default port.


Another false statement.
The ports framework has a DEFAULT_VERSIONS support which you can 
override via a profile mk.conf, just as poudriere does.  Doing so 
avoid surprises.  There is also an UPDATING file in the ports tree but 
that's more for portmaster and portupgrade users.
First of all, synth ignores /etc/make.conf completely. Yes, we 
definitely need another place to keep global make options, however 
DEFAULT_VERSIONS suggestion is a bad advice here.
Here is example: recently ports framework deprecated perl 5.20 and 
switched to 5.24
portmaster users should recompile all ports depended on perl (from my 
point of view this is done not very reliable), but when it comes to new 
perl, portmaster will invoke dialog4ports.
synth user with non-default perl options will receive new perl with 
default one. I hit this very problem during my synth test when I noticed 
pgadmin3 liked to postgresql93-client and added DEFAULT_VERSIONS to 96.





So, synth is just a dumb port building tool. If you need your own port
options you are in risk. Developer of synth said that the problem is in
my 'portmaster thinking' I should change.


An absurd assertion spoken loudly by someone that is ill-informed on 
the topic.
I see how synth can be used in pkg framework, I even agree that synth is 
poudriere done right and I feel I will use synth test feature for ports 
I maintain, what I fail to see, how I can use it to keep my laptop 
updated. I'm not asking for pony here, the examples I provided (if true) 
lead to overcomplexity maintaining packages up to date.


___
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"

The ports collection has some serious issues

2016-12-17 Thread John Marino 

abi wrote:

I tried to switch from portmaster to synth yesterday. Tests was
sponsored by zfs snapshots.

I still have strong opinion that synth IS NOT replacement for portmaster
and not usable at all.

Yes, synth build ports, however it's just builds them. I don't receive
information:

1. Why it builds exactly this list of ports, what has changed when I
upgraded my ports.


What you are apparently saying is that Synth wants to rebuild certain 
ports after you update your ports tree and you want the exact reaason 
why.  That reasoning is available via the WHYFAIL environment variable 
and the new 06_obsolete_packages.log file.


Unless you're hunting for bugs in synth, this information is "just for 
fun".  If your goal is to not rebuild packages when synth (and 
poudriere) say they must be rebuilt, then yes, portmaster is for you 
along with the consequences.



2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't
know what else will be pulled to my system after port tree update.


which of course is a false statement.
If you set port options which then change, Synth will stop and tell you 
to reconfigure or remove the saved port options.



2.2 If I make option files for all ports, synth fails to rebuild
repository if port and it's options are out of sync.


yes, of course.  If you give it impossible instructions, it will stop 
and ask you to fix them.  Any reasonable person would want to be 
informed when the options are incorrect.  Did you also notice that 
extended use of portmaster resulted in dozens of obsolete options files 
that you weren't aware of?  So your criticism here is that you think 
Synth should just ignore these bad configurations?



2.3 When port infrastructure switch to newer default version I must be
aware that this change occur and set damn options for new default port.


Another false statement.
The ports framework has a DEFAULT_VERSIONS support which you can 
override via a profile mk.conf, just as poudriere does.  Doing so avoid 
surprises.  There is also an UPDATING file in the ports tree but that's 
more for portmaster and portupgrade users.



So, synth is just a dumb port building tool. If you need your own port
options you are in risk. Developer of synth said that the problem is in
my 'portmaster thinking' I should change.


An absurd assertion spoken loudly by someone that is ill-informed on the 
topic.



Fuck it. Until synth gets interactive mode. Probably I will switch to
Linux (yes, I know nobody cares) if the ability to keep custom port
options will be lost. The only tool for this now is portmaster.


Regardless of how factually incorrect your evaluation of the other tools 
are, you have the freedom to make this choice.



Maybe it's my 'portmaster thinking' but I don't understand how one can
use synth if he or she want at least be slightly aware what's going on
in his/her system.


Because everyone else used synth (or poudriere) long enough to 
understand how those tools actually work.


John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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"

The ports collection has some serious issues

2016-12-17 Thread John Marino 

From Thomas Mueller:

From John Marino:
Starting with a clean system: 1) install synth from binary package
from official freebsd builder (a single
package) 2) Configure synth if necessary 3) command synth to build
itself 4) pkg delete synth (system is once again clean) 5) pkg add -F
/path/to/synth/packages/synth-*



Now you have a system containing s/w built by itself. On an modest
system less than 4 years old, it might take 30 minutes at most.


I believe you could cd $PORTSDIR/ports-mgmt/synth and
make package-recursive |& tee build-12amd64.log (or whatever you want to
name the log file; this example if for shell tcsh)?


That installs build dependencies on the system.  That would be no better 
than running portmaster the first time.  If you run the process I 
suggested, you'll end up with a self-hosted machine with no extra stuff 
installed.




For a system with pkgng, is there any difference in package format
between "make install", portmaster and portupgrade?


There shouldn't be, the ports framework is responsible for creating the 
package.



If your system already has portmaster, you could portmaster
ports-mgmt/synth |& tee synth-12amd64.log?

And then switch from portmaster to synth for all further ports
builds/updates?


sure.
Although it will still be dirty from portmaster so at that point you 
would gather a "prime list" of packages, feed thoughs into synth to 
create a local repository, remove all packages from the system and 
re-install them with the "prime list" and the new local repository.




It would not be necessary to start with a clean system for FreeBSD, as
opposed to NetBSD, or am I mistaken here?


No, you can start anytime but I do recommend the procedure above to 
ensure the system is in good shape and doesn't contain unnecessary 
package installations.


John





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 01:49, Hrant Dadivanyan wrote:


On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:

On 2016-Dec-15 19:31:22 +0100, list-freebsd-ports at jyborn.se wrote:
Interestingly, the most vocal proponent of deleting portmaster and
portupgrade is the author/maintainer of synch.


It's not interesting at all.  Synth was in a large part created because
people were irrationally sticking with portmaster and more frighteningly
gaining new users.



Please don't judge what's rational and what's not, because it's community
and when many people, even irrationally from your POV, sticking with
portmaster, then it's worth to consider and look for a way to keep it up.


Why don't *you* look for a way to keep it up?  TZ already said he is 
looking to drop maintainership.  Now *YOU* have the chance to do more 
than order volunteers around.





The point is that these tools are in great shape and to imply otherwise
needs proof.  It's portmaster that's not receiving updates.



In current shape it works well for many people (and demanded by) in
community, so why should it be removed ? You can warn as much as you want
against, but you can't decide to remove.

Hrant


Hrant, you must work on your reading comprehension.  Nobody has talked 
about removing portmaster, at all.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread John Marino 

On 12/17/2016 07:55, Michael Gmelin wrote:




On 17 Dec 2016, at 14:26, Alphons van Werven  wrote:

John Marino wrote:


In fact, anyone that updates ports should use either poudriere testport
or synth test.


Then consider these relinquished:

/usr/ports/archivers/zip
/usr/ports/astro/wmmoonclock
/usr/ports/astro/xearth
/usr/ports/devel/byaccj
/usr/ports/devel/csmith
/usr/ports/devel/gzstream
/usr/ports/devel/t1lib
/usr/ports/games/xroach
/usr/ports/games/xteddy
/usr/ports/graphics/hsetroot
/usr/ports/mail/xmailbox
/usr/ports/misc/fortune-mod-futurama
/usr/ports/science/gromacs
/usr/ports/security/chaosreader
/usr/ports/www/fcgi
/usr/ports/www/fcgiwrap
/usr/ports/x11/grabc
/usr/ports/x11/xdialog
/usr/ports/x11/xtrlock
/usr/ports/x11-fm/catseye-fm
/usr/ports/x11-fonts/cyberbit-ttfonts
/usr/ports/x11-servers/Xfstt

Please remove my e-mail address and mirror URL from the relevant
Makefiles.



Maybe you could elaborate a bit more what you find so annoying about running "poudriere 
testport origin" before doing "svn commit" that you are willing to drop port 
maintainership over it?

-m



Especially since "update ports" means "commit to ports" and Fonz doesn't 
have commit privileges.  It wasn't even directed at maintainers 
(although I would say that maintainers that don't test their updates 
aren't doing good work and relying on a committer to catch obvious 
mistakes).


I like Fonz a lot but that is pure drama queen stuff right there.

"Check your work, please".  "I quit".  Ok.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
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 ports collection has some serious issues

2016-12-17 Thread Grzegorz Junka 



On 17/12/2016 13:22, Torfinn Ingolfsen wrote:

On Fri, Dec 16, 2016 at 3:45 PM, John Marino  wrote:

Now, regarding synth: as I have already said, I have no special
interest in package builders. I do need a tool to build and install
the ports I use, and my current tool (portupgrade or manual building)
still works for that.
I might try synth in the future sometime, but for tools that I have no
special interest in, I prefer that they are a bit more mature. I use
my own "metric" to measure maturity of a tool - I read users's
feedback in forums and mailinglists, and filter out PEBCACs and other
"new user - new tool" issues. Based on that, I will consider using a
tool when the discussions around it has quieted down to a reasonable
level. All subjective, all by my own standards.

If you still find this though to handle and an accusation, my
suggestion would be for you to take a long holiday break from
computers and spend time with friends and family.
Best wishes for the holidays for everyone!


I believe the main point is that portupgrade/portmaster shouldn't be 
used by default by newcomers to FreeBSD. It easily breaks and if you 
have no knowledge about the system, you will post questions to this 
list, which seems to be annoying people.


I tried to used portupgrade/portmaster in the past and whereas it's fine 
with small amount of packages, is unusable when there is a few hundred 
or thousand of them installed. Very often the build was leaving my 
system messed up because some port only partially build and half of the 
dependencies were reinstalled and the other half were not. There is no 
undo in those tools. It's essentially press enter and pray.


Grzegorz
___
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: www/h2o needs a committer [BZ#213733]

2016-12-17 Thread Dave Cottlehuber 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213733

www/h2o update this still needs a committer - I am getting bugged by
users waiting for this to land. thanks!

A+
Dave
___
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 ports collection has some serious issues

2016-12-17 Thread Michael Gmelin 


> On 17 Dec 2016, at 14:26, Alphons van Werven  wrote:
> 
> John Marino wrote:
> 
>> In fact, anyone that updates ports should use either poudriere testport
>> or synth test.
> 
> Then consider these relinquished:
> 
> /usr/ports/archivers/zip
> /usr/ports/astro/wmmoonclock
> /usr/ports/astro/xearth
> /usr/ports/devel/byaccj
> /usr/ports/devel/csmith
> /usr/ports/devel/gzstream
> /usr/ports/devel/t1lib
> /usr/ports/games/xroach
> /usr/ports/games/xteddy
> /usr/ports/graphics/hsetroot
> /usr/ports/mail/xmailbox
> /usr/ports/misc/fortune-mod-futurama
> /usr/ports/science/gromacs
> /usr/ports/security/chaosreader
> /usr/ports/www/fcgi
> /usr/ports/www/fcgiwrap
> /usr/ports/x11/grabc
> /usr/ports/x11/xdialog
> /usr/ports/x11/xtrlock
> /usr/ports/x11-fm/catseye-fm
> /usr/ports/x11-fonts/cyberbit-ttfonts
> /usr/ports/x11-servers/Xfstt
> 
> Please remove my e-mail address and mirror URL from the relevant
> Makefiles.
> 

Maybe you could elaborate a bit more what you find so annoying about running 
"poudriere testport origin" before doing "svn commit" that you are willing to 
drop port maintainership over it?

-m
___
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 ports collection has some serious issues

2016-12-17 Thread Alphons van Werven 
John Marino wrote:

> In fact, anyone that updates ports should use either poudriere testport
> or synth test.

Then consider these relinquished:

/usr/ports/archivers/zip
/usr/ports/astro/wmmoonclock
/usr/ports/astro/xearth
/usr/ports/devel/byaccj
/usr/ports/devel/csmith
/usr/ports/devel/gzstream
/usr/ports/devel/t1lib
/usr/ports/games/xroach
/usr/ports/games/xteddy
/usr/ports/graphics/hsetroot
/usr/ports/mail/xmailbox
/usr/ports/misc/fortune-mod-futurama
/usr/ports/science/gromacs
/usr/ports/security/chaosreader
/usr/ports/www/fcgi
/usr/ports/www/fcgiwrap
/usr/ports/x11/grabc
/usr/ports/x11/xdialog
/usr/ports/x11/xtrlock
/usr/ports/x11-fm/catseye-fm
/usr/ports/x11-fonts/cyberbit-ttfonts
/usr/ports/x11-servers/Xfstt

Please remove my e-mail address and mirror URL from the relevant
Makefiles.

-- 
A.J. "Fonz" van Werven 
mailsig: Help! I'm a prisoner in a Chinese fortune cookie factory.


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

2016-12-17 Thread Torfinn Ingolfsen 
On Fri, Dec 16, 2016 at 3:45 PM, John Marino  wrote:
>>
>
>> I won't say "never". But I feel that both package builders (poudriere,
>> synth) need some more time to shake out more issues / bugs and get
>> into a better shape first. This isn't based on any specific problems
>> or bugs, more a "felleing2 based on people's feedback in the forums
>> and on mailing lists.

FWIW, the above was written by me, not by Peter Jeremy - the quoting
got a bit messed up here.

> I insist that you base this on "specific problems".  Speaking for Synth,
> there are no known bugs in it.  There are no pending issues with existing
> features.  It is updated frequently.  AFAIK poudriere is updated regularly
> as well.  The above is an accusation that you absolutely must back up with
> fact because it's basically defamation.

Defamation? Accusation? Strong words, and not my intention at all.
First of all - anyone can create what he or she wants. And he or she
can use whatever logic, reasoning or other means (marketing for
example) to get people to use that creation. If people like the
creation they will use it, based on their own criteria for using it -
not necessarily based on *anything* the creator of said creation has
presented at all. Unless the creator is a controlling authority (a
government creating new laws that require that everybody drive on the
right side of the road for example) he or she can't force anyone to
use that creation. And no, it doesn't matter if the creation is the
best such creation in the world and it has benchmarks to back it up.

Now, regarding synth: as I have already said, I have no special
interest in package builders. I do need a tool to build and install
the ports I use, and my current tool (portupgrade or manual building)
still works for that.
I might try synth in the future sometime, but for tools that I have no
special interest in, I prefer that they are a bit more mature. I use
my own "metric" to measure maturity of a tool - I read users's
feedback in forums and mailinglists, and filter out PEBCACs and other
"new user - new tool" issues. Based on that, I will consider using a
tool when the discussions around it has quieted down to a reasonable
level. All subjective, all by my own standards.

If you still find this though to handle and an accusation, my
suggestion would be for you to take a long holiday break from
computers and spend time with friends and family.
Best wishes for the holidays for everyone!
-- 
Regards,
Torfinn Ingolfsen
___
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 ports collection has some serious issues

2016-12-17 Thread Jeffrey Bouquet via freebsd-ports 

tacking a slightly off-topic topic onto this one


On 12/15/16 10:31 AM, list-freebsd-po...@jyborn.se wrote:

On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:

On 12/15/16 09:40, Warren Block wrote:

On Thu, 8 Dec 2016, Matt Smith wrote:


On Dec 08 05:16, Daniil Berendeev wrote:

Although portmaster is not releated to the FreeBSD project and is an
outside tool, there aren't any alternatives from the project itself. So
use it or die. Not a nice situation.

People have been trying to get portmaster deprecated and removed from
the handbook but have met with resistance.

Well, yes.  Because it works, has no dependencies, and there is no
equivalent replacement.  [...]

Warren, you have hit the nail on the head.  -- George

+1

I never have problems with portmaster.
(But portupgrade could at times be an utter mess,
I never looked back after switching to portmaster
many years ago.)

And I'm not at all interested in running poudriere
or synth, thank you.

Peter
___
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"

synth here: silently fails, year in year out
synth on a new install equal to this one: good to go
poudriere:  inexpert, hundreds of .htm saved for howto
portmanager:  MOVED, saved hours debugging portupgrade/portmaster until 
it started not working so well.
custom .sh   :   did most of what portmaster did, sometimes very rarely 
in use

edited locally portmaster:  fail at coding on my part
portmaster:  has worked mostly, gave up recently though.  Really would 
like it fully pkg compliant
portupgrade:  features since /var/db/pkg/DIRECTORIES not front-ended by 
sqlite3 expertise required have not worked, pkgdb -F for example

   IIRC

All of those restored to 2006 goodness and working together seamlessly?  
I cannot wait.  Possible with enough systemd-too-complex

systems migrated to FreeBSD someday may happen...

But the reason for this add-on to that topic:
due to gcc gcc49 conflicts I was forced to desinstall math/ised.
Now:  if one will pardon xclip pasted in formatting:

pkg-static install ised Updating FreeBSD repository catalogue... FreeBSD 
repository is up-to-date. All repositories are up-to-date. pkg-static: 
hugin has a missing dependency: autopano-sift-C pkg-static: truecrypt 
has a missing dependency: fusefs-kmod Checking integrity... done (2 
conflicting) - gcc-4.9.4 conflicts with gcc49-4.9.4_1 on 
/usr/local/bin/i386-portbld-freebsd11.0-c++49 - gcc-4.9.4 conflicts with 
gcc49-4.9.4_1 on /usr/local/bin/i386-portbld-freebsd11.0-c++49 Checking 
integrity... done (0 conflicting) The following 33 package(s) will be 
affected (of 0 checked):


 Installed packages to be REMOVED: truecrypt-7.1a_3 gcc49-4.9.4_1 
ircii-20151120 py34-setuptools_scm-1.10.1 py34-msgpack-python-0.4.7 
3dm-2.11.00.021_1,1 py34-llfuse-1.0 xalarm-3.06_3 p5-PDF-Template-0.22_1 
pdflib-perl-7.0.5_2 xpi-web_developer-1.2.2 pathneck-1.3 mpack-1.6_3 
webcopy-0.98b7 lha-ac-1.14i_10 lv-4.51_3 window-1.0 solarized-1.0.0 
freefonts-0.10_7 weedit-2.0.3 ncp-1.2.4 shorten-3.6.1 jail-primer-0.2 
lynis-2.4.0 win32-codecs-20110131,1 areca-cli-i386-1.14.7.150519,1 
pkg_cleanup-2.1 sscalc-1.0 New packages to be INSTALLED: ised: 2.7.1_1 
gcc: 4.9.4 dejavu: 2.37 Installed packages to be REINSTALLED: pkg-1.9.4 
opera-12.16_6 (options changed)


Number of packages to be removed: 28
Number of packages to be installed: 3
Number of packages to be reinstalled: 2
The operation will free 103 MiB.
13 MiB to be downloaded.
Proceed with this action? [y/N]: n

Additionally, it does not build. Maybe on the other machine that synth 
runs on, I could put it on a thumbdrive and install just

the ised binary...

Also had to deinstall scilab, PDL, py27-game, solarwolf, etc etc. IIRC

Nothing urgent at all but my thoughts on this gcc conflict issue as well 
as maybe chiming into the topic of this thread
Sorry to waste anyone's time, may be a local issue to this particular 
ports tree, some errant file.

___
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 ports collection has some serious issues

2016-12-17 Thread abi 
I tried to switch from portmaster to synth yesterday. Tests was 
sponsored by zfs snapshots.


I still have strong opinion that synth IS NOT replacement for portmaster 
and not usable at all.


Yes, synth build ports, however it's just builds them. I don't receive 
information:


1. Why it builds exactly this list of ports, what has changed when I 
upgraded my ports.

2. It doesn't provide dialog for port options, so
2.1 I don't receive information if port options have changed. I don't 
know what else will be pulled to my system after port tree update.
2.2 If I make option files for all ports, synth fails to rebuild 
repository if port and it's options are out of sync.
2.3 When port infrastructure switch to newer default version I must be 
aware that this change occur and set damn options for new default port.


So, synth is just a dumb port building tool. If you need your own port 
options you are in risk. Developer of synth said that the problem is in 
my 'portmaster thinking' I should change.


And now I see that he tried to deprecate portmaster!

Fuck it. Until synth gets interactive mode. Probably I will switch to 
Linux (yes, I know nobody cares) if the ability to keep custom port 
options will be lost. The only tool for this now is portmaster.


Maybe it's my 'portmaster thinking' but I don't understand how one can 
use synth if he or she want at least be slightly aware what's going on 
in his/her system.



On 17.12.2016 10:49, Hrant Dadivanyan wrote:


On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:

On 2016-Dec-15 19:31:22 +0100, list-freebsd-ports at jyborn.se wrote:
Interestingly, the most vocal proponent of deleting portmaster and
portupgrade is the author/maintainer of synch.


It's not interesting at all.  Synth was in a large part created because
people were irrationally sticking with portmaster and more frighteningly
gaining new users.



Please don't judge what's rational and what's not, because it's community
and when many people, even irrationally from your POV, sticking with
portmaster, then it's worth to consider and look for a way to keep it up.


The point is that these tools are in great shape and to imply otherwise
needs proof.  It's portmaster that's not receiving updates.



In current shape it works well for many people (and demanded by) in
community, so why should it be removed ? You can warn as much as you want
against, but you can't decide to remove.


___
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: Gettext Issues

2016-12-17 Thread Tijl Coosemans 
On Fri, 16 Dec 2016 17:17:52 -0700 "@lbutlr"  wrote:
>> On 16 Dec 2016, at 00:22, @lbutlr  wrote:
>>> 2014-11-30
>>> Affects: users of devel/gettext (close to everyone)
>>> Author: t...@freebsd.org
>>> Reason:
>>>  The devel/gettext port has been split up in devel/gettext-runtime, a
>>>  lightweight package containing runtime libraries, and devel/gettext-tools,
>>>  a package containing developer tools.  The devel/gettext port still exists
>>>  as a metaport.
>>> 
>>>  You must first delete the existing installation of gettext and then
>>>  reinstall it.  This will break sudo, so you *must* do this in a root
>>>  shell (sudo -i) if you use sudo.
>> 
>> I cannot imagine that gettext hasn't been updated on my system in over
>> 2 years, but I seem to be having an issue that appears to be related
>> to this based on the errors.
>> 
>> Shared object "libintl.so.8" not found, required by "bash"
>> 
>> For example.
>> 
>> I have logged into the console directly as the root user and tried to
>> build gettext via portmaster of via make clean && make install but I
>> get errors about missing files.
>> 
>> pkg-static: Unable to access file
>> /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h:
>> No such file or directory
>> 
>> 
>> I've tried to build gettext-runtime first, but to no avail.
> 
> To clarify, if I try to make gettext-runtime it ends with:
> 
> install  -m 0644 ABOUT-NLS 
> '/usr/ports/devel/gettext-runtime/work/stage/usr/local/share/gettext'
> > Compressing man pages (compress-man)  
> ls: 
> /usr/ports/devel/gettext-runtime/work/stage/usr/local/info/autosprintf.info*: 
> No such file or directory
> 
> And the error is correct, the file does not exist.

Can you email me
/usr/ports/devel/gettext-runtime/work/gettext-0.19.8.1/gettext-runtime/config.log
___
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 ports collection has some serious issues

2016-12-17 Thread Dave Cottlehuber 
On Fri, 16 Dec 2016, at 16:34, Roger Marquis wrote:
> If portmaster was part of base I'd agree that it should be deprecated,
> however, being a port it can be afforded more leeway.  All portmaster
> needs IMO is a strong WARNING message to be displayed on installation A)
> enumerating some of the potential bugs and B) clarifying that portmaster
> is third party software that is neither actively maintained nor
> supported (or recommended?) by FreeBSD.
> 
> Roger

^ this ^

The key thing that needs to change for newcomers (as a recent one
myself) is to give a clear & simple recommendation in the Handbook.. not
in ports or whatever after you've sifted the internet looking for more
information

- the implications of choosing pkg quarterly vs pkg latest, vs
poudriere, portmaster etc is not at all clear
- it's hard to know what is project supported vs community supported
- knowing that e.g. DFLY uses synth exclusively now, and the the FreeBSD
build cluster uses poudriere, gives a warm fuzzy feeling

Some illustrative use cases are:

- sysadmin for servers
- personal user who needs custom options

I was lucky to run into the first poudriere episode from bsdnow.tv and
went with that from the get-go. synth's documentation is superb and
keeps getting better. Both are excellent tools.

A+
Dave
___
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 you maintain which are out of date

2016-12-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
+-+
net-mgmt/mk-livestatus  | 1.2.8p13| 1.2.8p15
+-+


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 ports collection has some serious issues

2016-12-17 Thread Thomas Mueller 
>From John Marino:

> At face value, this doesn't make sense because synth is a tool for building
> everything from source, so your development system is exactly where it should
> be installed.

> So you must be talking about build dependencies of synth (there are no run
> dependencies).  While I think the requirement of rebuilding synth from source
> is artificial, I've provided a very reasonable approach to solving this which
> I feel compelled to repeat for the readers of Kevin's post.  The solution:

> Starting with a clean system:
> 1) install synth from binary package from official freebsd builder (a single
> package)
> 2) Configure synth if necessary
> 3) command synth to build itself
> 4) pkg delete synth (system is once again clean)
> 5) pkg add -F /path/to/synth/packages/synth-*

> Now you have a system containing s/w built by itself.  On an modest system
> less than 4 years old, it might take 30 minutes at most.

> So the "synth has dependencies" detraction is extremely weak.  For people that
> trust FreeBSD to provide untainted binaries, it's not an issue at all and for
> the paranoid, it's easily worked around.  Saying that the use of Ada limits it
> to the platforms it can run on natively is a valid detraction, but it's BUILD
> dependencies really aren't due to the availability of binary packages, the
> PRIMARY product of the ports tree.

> RE: poudriere, it has no dependencies.  It's just as appropriate on the dev
> system and adding a jail and configuring it also takes less than 30 minutes.
> Either is very appropriate for a system that must build everything that is run
> on it.

I believe you could cd $PORTSDIR/ports-mgmt/synth and
make package-recursive |& tee build-12amd64.log (or whatever you want to name 
the log file; this example if for shell tcsh)?

For a system with pkgng, is there any difference in package format between 
"make install", portmaster and portupgrade?

If your system already has portmaster, you could portmaster ports-mgmt/synth |& 
tee synth-12amd64.log?

And then switch from portmaster to synth for all further ports builds/updates?

It would not be necessary to start with a clean system for FreeBSD, as opposed 
to NetBSD, or am I mistaken here?

First port-upgrading tool I used in FreeBSD was portupgrade.  Subsequently I 
switched to portmaster.

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"