Re: The ports collection has some serious issues

[George Mitchell]

On 12/26/16 03:11, Thomas Mueller wrote:
> [...]
> What is the current status of portupgrade and portmaster?
> 
> Maintained, deprecated or something else?
> 
> Tom
> [...]

If "contentious" were an official state, that would be it.  Each has
its enthusiastic adherents; others are, shall we say, less enthusiastic.
-- George

___
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

[Kurt Jaeger]

Hi!

> What is the current status of portupgrade and portmaster?
> 
> Maintained, deprecated or something else?

portupgrade: MAINTAINER= bdrew...@freebsd.org

portmaster: MAINTAINER= t...@freebsd.org

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

Re: The ports collection has some serious issues

[Thomas Mueller]

> On Tue, Dec 20, 2016 at 11:57:38PM +1100, Dave Horsfall wrote:
> > On Mon, 19 Dec 2016, John Marino wrote:

> > > I never, not once, tried to "get rid of portmaster".  By repeating this
> > > untruth after I already corrected you is trolling.  There was a very
> > > small chance you were just ignorant but thanks for admitting you knew
> > > exactly what you were doing and making Dave H. look silly.

> > > What I have (and others) wanted?  What would make us happy?

> > Perhaps for you to just quietly FOAD?  When it comes to common sense, you
> > appear to be utterly impervious.


> The direction this thread is taking is intollerable in our community, please
> stay polite and keep this discussion civil (or rather bring it back to a civil
> discussion).

> We will not accept such insults in our community

> Bapt

I just looked in svnweb.freebsd.org, cvsweb.netbsd.org and the FreeBSD handbook.

What is the current status of portupgrade and portmaster?

Maintained, deprecated or something else?

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

[Torsten Zuehlsdorff]

On 21.12.2016 12:32, John Marino wrote:

On 12/21/2016 01:23, Jim Trigg wrote:

Therefore my first
assumption was that the problem was the new tool I had just started
using. Note: while my phrasing may have been poor, I was not meaning to
imply that the tool (poudriere) was necessarily broken, just that I
couldn't figure out what was going wrong and that it seemed (based on my
data sample) to be poudriere rather than the port. Having now tested
using the ports tree directly (make -C
/usr/ports/databases/php70-pdo_mysql on a basically clean ports tree
with "OPTIONS_SET+= ZTS" in /etc/make.conf) and gotten the same failure
as with poudriere, I now have no idea how it worked in portmaster, and
acknowledge that it is a problem with the port.


Okay, good.
Any time you can produce an error with poudriere, it should be easy for
others to reproduce as well which confirms the error.


The bug was already reported and fixed, but this was not very 
transparent for users. I need to dig into the framework to find a 
solution (and another user hit by the problem was a little bit faster 
than me).


For PHP 7.0 i added a message to make thinks more clear in:
https://svnweb.freebsd.org/changeset/ports/429051

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

[John Marino]

On 12/21/2016 01:23, Jim Trigg wrote:

No, that's not what I'm saying. I can't find anything online showing
that this problem has been reported.


I've see this reported before, probably on this list, maybe by you.


I can't reproduce it using the tool
that I've been using for years (portmaster).


Which by itself only indicates a portmaster weakness.


Therefore my first
assumption was that the problem was the new tool I had just started
using. Note: while my phrasing may have been poor, I was not meaning to
imply that the tool (poudriere) was necessarily broken, just that I
couldn't figure out what was going wrong and that it seemed (based on my
data sample) to be poudriere rather than the port. Having now tested
using the ports tree directly (make -C
/usr/ports/databases/php70-pdo_mysql on a basically clean ports tree
with "OPTIONS_SET+= ZTS" in /etc/make.conf) and gotten the same failure
as with poudriere, I now have no idea how it worked in portmaster, and
acknowledge that it is a problem with the port.


Okay, good.
Any time you can produce an error with poudriere, it should be easy for 
others to reproduce as well which confirms the error.


Honestly, if personX reports an error, tells me he uses portmaster, and 
not not try to reproduce with poudriere, I (and likely most committers) 
will disregard the report -- or at the very least ask them to report 
back if they can confirm with poudriere.



It doesn't seem to have been fixed, since I'm still seeing the error.
I'm saying that 90% of the time portmaster works for me, and when it
doesn't I can figure out a solution 90% of that time. I haven't gotten
poudriere to work for me yet given the set of options I need set.


Did you open a PR on https://bugs.freebsd.org/bugzilla/ ?
Once you report something, after 2 weeks of inactivity you have the 
right to ping this list (in the worst case of your report being ignored).


It's not the tool's fault when the port itself is broken and the port 
can't be fixed if nobody reports issues with non-default options.




But you will tell a portmaster user to switch if they are happy with
portmaster because it doesn't do things the way you think they should be
done...


yes.  It's not a subjective thing.  Anybody that knows what they are 
talking about agrees.  If anyone tries to sell you that portmaster is 
"just as good" as poudriere, they are at best ignorant as hell.


You bring up a real-life case right here in this thread.


Never mind that the whole pkgng system was forced on us
willy-nilly, and it's the main reason there are problems with
portmaster.


wow.  No, this is absolutely false.  You need to cleanse your head from 
thoughts like these.  The only role pkgng even has in building is 
physical packaging and basic dependency checking.  None of that has 
*anything* to do with the fundamental issues of portmaster.


 >Note that the "cannot as yet contest this" is because I'm

not convinced that synth is "more effective" than poudriere - I expect
that they are each better suited for a particular use case. The
difference is that as far as I can tell, poudriere is satisfactory for
the use case synth is designed for, but synth is not suited for the use
case poudriere was initially intended for. (Note that a primary use of
poudriere is/was to replace the now extinct port tinderbox.)


Luckily you don't need to contest it.  A clock is a clock, a benchmark 
is a benchmark, and they are by design, objective.  Doing the same exact 
set of tasks, Synth will do the job much faster.  It's objectively much 
faster to set up.


Subjectively people say it's easier for new users to grasp.

There are a couple of specific features poudriere does that synth does 
not (e.g. cross building with QEMU and blocking network during build 
phase) but the vast majority of users don't require these features and 
if they do, poudriere is the only game in town.


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

[Jim Trigg]

On 12/19/2016 09:02 AM, John Marino wrote:

On 12/18/2016 23:42, Jim Trigg wrote:

On 12/18/2016 02:24 AM, John Marino wrote:

2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)


Maybe. I have a case where portmaster (on my current production box)
builds fine but poudriere (on my intended replacement production box)
does not.

Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
failed. This time (after correcting other ports' option problems)
pdo_mysql fails for basically the same reason - pdo_* cannot find pdo
because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks
PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the
build with postmaster works fine.


Wasn't that a global bug that was fixed?7


I don't know; I can't find any record of it...\


You logic is faulty IMO.  All binary packages produced officially for
FreeBSD are built with poudriere.  If poudriere can't build it due to a
bug in the port itself, then nobody gets the package.  Obviously that's
unacceptable, so the port bug gets fixed, quickly.


All binary packages produced officially for FreeBSD are built with 
poudriere *with default options*. ZTS is not the default (even though 
it's needed in most cases for mod_php and apache).



So it sounds like you're saying that poudriere is too strict at
enforcing correctness and you need something more forgiving?


No, that's not what I'm saying. I can't find anything online showing 
that this problem has been reported. I can't reproduce it using the tool 
that I've been using for years (portmaster). Therefore my first 
assumption was that the problem was the new tool I had just started 
using. Note: while my phrasing may have been poor, I was not meaning to 
imply that the tool (poudriere) was necessarily broken, just that I 
couldn't figure out what was going wrong and that it seemed (based on my 
data sample) to be poudriere rather than the port. Having now tested 
using the ports tree directly (make -C 
/usr/ports/databases/php70-pdo_mysql on a basically clean ports tree 
with "OPTIONS_SET+= ZTS" in /etc/make.conf) and gotten the same failure 
as with poudriere, I now have no idea how it worked in portmaster, and 
acknowledge that it is a problem with the port.



Unfortunately, port maintainers break the tree.  Usually the big breaks
are avoid with EXP-RUNs but it's common to see updates where downstream
dependencies weren't tested and break (aside: IMO this it is the
responsibility of the person updating the first port to verify the deps
still build but not everyone does this).

So sometimes you hit a tree break and that's what happened.  It was
fixed right?  The bottom line: if a port doesn't build on poudriere and
synth, the issue must be fixed, not worked around by using a tool
incapable of detecting it.  That's how most of the "I use portmaster and
this doesn't work" topics get started.


It doesn't seem to have been fixed, since I'm still seeing the error. 
I'm saying that 90% of the time portmaster works for me, and when it 
doesn't I can figure out a solution 90% of that time. I haven't gotten 
poudriere to work for me yet given the set of options I need set.



4) There's a second, even more effective alternative for x86 platforms
(true)


I can not as yet contest this. I haven't tried synth because if
poudriere works it will have further value add for me (as a port
maintainer I can build my port in multiple environments on a single
box). Dealing with the conversion factor isn't worth it to me for the
alleged gains synth brings.


I am a big supporter of poudriere.  While many people find they prefer
synth and enjoy its performance advantage, I will never tell a poudriere
user to switch if they are happy with poudriere.


But you will tell a portmaster user to switch if they are happy with 
portmaster because it doesn't do things the way you think they should be 
done... Never mind that the whole pkgng system was forced on us 
willy-nilly, and it's the main reason there are problems with 
portmaster. Note that the "cannot as yet contest this" is because I'm 
not convinced that synth is "more effective" than poudriere - I expect 
that they are each better suited for a particular use case. The 
difference is that as far as I can tell, poudriere is satisfactory for 
the use case synth is designed for, but synth is not suited for the use 
case poudriere was initially intended for. (Note that a primary use of 
poudriere is/was to replace the now extinct port tinderbox.)


Jim Trigg
___
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

[Baptiste Daroussin]

On Tue, Dec 20, 2016 at 11:57:38PM +1100, Dave Horsfall wrote:
> On Mon, 19 Dec 2016, John Marino wrote:
> 
> > I never, not once, tried to "get rid of portmaster".  By repeating this 
> > untruth after I already corrected you is trolling.  There was a very 
> > small chance you were just ignorant but thanks for admitting you knew 
> > exactly what you were doing and making Dave H. look silly.
> > 
> > What I have (and others) wanted?  What would make us happy?
> 
> Perhaps for you to just quietly FOAD?  When it comes to common sense, you 
> appear to be utterly impervious.
> 

The direction this thread is taking is intollerable in our community, please
stay polite and keep this discussion civil (or rather bring it back to a civil
discussion).

We will not accept such insults in our community

Bapt


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[David Demelier]

2016-12-20 13:57 GMT+01:00 Dave Horsfall :
> Perhaps for you to just quietly FOAD?  When it comes to common sense, you
> appear to be utterly impervious.

Perhaps we can stay polite?

-- 
Demelier David
___
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

[Dave Horsfall]

On Mon, 19 Dec 2016, John Marino wrote:

> I never, not once, tried to "get rid of portmaster".  By repeating this 
> untruth after I already corrected you is trolling.  There was a very 
> small chance you were just ignorant but thanks for admitting you knew 
> exactly what you were doing and making Dave H. look silly.
> 
> What I have (and others) wanted?  What would make us happy?

Perhaps for you to just quietly FOAD?  When it comes to common sense, you 
appear to be utterly impervious.

-- 
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: Subscription for committer (was: Re: The ports collection has some serious issues)

[Thomas Mueller]

> 17.12.2016 22:40, John Marino пишет:

>> I am not subscribed to the mail list

> A port's committer is not subscribed to the ports@ ML?
> Is it a joke?

> WBR, Boris Samorodov (bsam)

When I see frequent posts by somebody on a mailing list, I assume that person 
is a regular and don't CC to that person when I reply.  I guess I was wrong in 
this case.

I believe the practice on most other emailing lists is to reply to the list and 
not CC to individual posters.

Most of the time, I don't think about looking for the Reply-To header line.


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

[Baptiste Daroussin]

On Mon, Dec 19, 2016 at 12:42:30AM -0500, Jim Trigg wrote:
> On 12/18/2016 02:24 AM, John Marino wrote:
> > 2) portmaster's dirty build method is inferior to clean environment
> > builds (true)
> > 3) There is better and official alternative (true)
> 
> Maybe. I have a case where portmaster (on my current production box) builds
> fine but poudriere (on my intended replacement production box) does not.
> 
> Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
> failed. This time (after correcting other ports' option problems) pdo_mysql
> fails for basically the same reason - pdo_* cannot find pdo because pdo
> thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks PHP_EXT_DIR=20151012 - log
> for the latter below signature. Yet doing the build with postmaster works
> fine.

This is a big in the php framework that has been reported very long ago and
noone care about, poudriere is doing the right thing here by failing and
reporting the actually issue of the framework on that subject.

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[John Marino]

On 12/18/2016 23:42, Jim Trigg wrote:

On 12/18/2016 02:24 AM, John Marino wrote:

2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)


Maybe. I have a case where portmaster (on my current production box)
builds fine but poudriere (on my intended replacement production box)
does not.

Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
failed. This time (after correcting other ports' option problems)
pdo_mysql fails for basically the same reason - pdo_* cannot find pdo
because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks
PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the
build with postmaster works fine.


Wasn't that a global bug that was fixed?
You logic is faulty IMO.  All binary packages produced officially for 
FreeBSD are built with poudriere.  If poudriere can't build it due to a 
bug in the port itself, then nobody gets the package.  Obviously that's 
unacceptable, so the port bug gets fixed, quickly.


So it sounds like you're saying that poudriere is too strict at 
enforcing correctness and you need something more forgiving?


Unfortunately, port maintainers break the tree.  Usually the big breaks 
are avoid with EXP-RUNs but it's common to see updates where downstream 
dependencies weren't tested and break (aside: IMO this it is the 
responsibility of the person updating the first port to verify the deps 
still build but not everyone does this).


So sometimes you hit a tree break and that's what happened.  It was 
fixed right?  The bottom line: if a port doesn't build on poudriere and 
synth, the issue must be fixed, not worked around by using a tool 
incapable of detecting it.  That's how most of the "I use portmaster and 
this doesn't work" topics get started.



4) There's a second, even more effective alternative for x86 platforms
(true)


I can not as yet contest this. I haven't tried synth because if
poudriere works it will have further value add for me (as a port
maintainer I can build my port in multiple environments on a single
box). Dealing with the conversion factor isn't worth it to me for the
alleged gains synth brings.


I am a big supporter of poudriere.  While many people find they prefer 
synth and enjoy its performance advantage, I will never tell a poudriere 
user to switch if they are happy with poudriere.


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

[John Marino]

On 12/19/2016 00:48, Peter Jeremy wrote:

On 2016-Dec-17 20:16:12 -0600, John Marino <freebsd.cont...@marino.st> 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.

It's been mentioned several times in this thread alone that Ada is only
available for i386 and amd64.


Not in this thread, no it hasn't.  I went digging and found that it has been
mentions in some of the other 7 separate "The ports collection has some
serious issues" that you have started.


I think you already knew that


Well, I pointed it out to you in February this year and after 10 months,
nothing has changed, including your persistent desire to get rid of
portmaster, despite the fact that synth is not a suitable replacement.


and thus
this is a pure troll.


I insist that you retract that insult.  In this thread, without any
qualification, you stated that anyone who used portmaster or portupgrade
should swap to synth, and gave a process which you know will only work on
i386 and amd64.


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


I haven't investigated because I haven't had the the need to.



I never, not once, tried to "get rid of portmaster".  By repeating this 
untruth after I already corrected you is trolling.  There was a very 
small chance you were just ignorant but thanks for admitting you knew 
exactly what you were doing and making Dave H. look silly.


What I have (and others) wanted?  What would make us happy?

A warning placed on the port (a deprecation message but no expiration 
date) and others have suggested the same message at installation time in 
the form of a pkg-message.


That's it.  Nobody ever tried to remove it.

You are like a die-hard smoker that doesn't want "Cancer kills" stickers 
on their cigarette boxes.  Ask yourself why you don't want people to be 
informed?


Joh

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

[Julian Elischer]

On 18/12/2016 10:16 AM, 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.

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.


or use  portmaster, which works really 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"




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

Subscription for committer (was: Re: The ports collection has some serious issues)

[Boris Samorodov]

17.12.2016 22:40, John Marino пишет:

> I am not subscribed to the mail list

A port's committer is not subscribed to the ports@ ML?
Is it a joke?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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

[David Demelier]

2016-12-18 21:22 GMT+01:00 Kevin Oberman :
> synth(8)... try it, you'll like it. (Sorry, dating myself.)

I also never tried synth as I'm very familiar with poudriere, but I'll
have a look for sure :)

-- 
Demelier David
___
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

[Peter Jeremy]

On 2016-Dec-17 20:16:12 -0600, John Marino <freebsd.cont...@marino.st> 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.
>
>It's been mentioned several times in this thread alone that Ada is only 
>available for i386 and amd64.

Not in this thread, no it hasn't.  I went digging and found that it has been
mentions in some of the other 7 separate "The ports collection has some
serious issues" that you have started.

> I think you already knew that

Well, I pointed it out to you in February this year and after 10 months,
nothing has changed, including your persistent desire to get rid of
portmaster, despite the fact that synth is not a suitable replacement.

>and thus 
>this is a pure troll.

I insist that you retract that insult.  In this thread, without any
qualification, you stated that anyone who used portmaster or portupgrade
should swap to synth, and gave a process which you know will only work on
i386 and amd64.

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

I haven't investigated because I haven't had the the need to.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[Jim Trigg]

On 12/18/2016 02:24 AM, John Marino wrote:

2) portmaster's dirty build method is inferior to clean environment
builds (true)
3) There is better and official alternative (true)


Maybe. I have a case where portmaster (on my current production box) 
builds fine but poudriere (on my intended replacement production box) 
does not.


Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite 
failed. This time (after correcting other ports' option problems) 
pdo_mysql fails for basically the same reason - pdo_* cannot find pdo 
because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks 
PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the 
build with postmaster works fine.



4) There's a second, even more effective alternative for x86 platforms
(true)


I can not as yet contest this. I haven't tried synth because if 
poudriere works it will have further value add for me (as a port 
maintainer I can build my port in multiple environments on a single 
box). Dealing with the conversion factor isn't worth it to me for the 
alleged gains synth brings.


--
Jim Trigg

Log for php70-pdo_mysql
>> Building databases/php70-pdo_mysql
build started at Sun Dec 18 23:53:21 EST 2016
port directory: /usr/ports/databases/php70-pdo_mysql
building for: FreeBSD freebsd_10-3x64-HEAD-job-04 10.3-RELEASE-p14 
FreeBSD 10.3-RELEASE-p14 amd64

maintained by: t...@freebsd.org
Makefile ident:  $FreeBSD: head/databases/php70-pdo_mysql/Makefile 
422569 2016-09-21 15:43:47Z tz $

Poudriere version: 3.1.14
Host OSVERSION: 1003000
Jail OSVERSION: 1003000

---Begin Environment---
SHELL=/bin/csh
UNAME_v=FreeBSD 10.3-RELEASE-p14
UNAME_r=10.3-RELEASE-p14
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
ARCH=amd64
SAVED_TERM=screen
MASTERMNT=/srv/poudriere/data/.m/freebsd_10-3x64-HEAD/ref
UID=0
FORCE_PACKAGE=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=php70-pdo_mysql-7.0.14
OSREL=10.3
_OSRELEASE=10.3-RELEASE-p14
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=4
PWD=/srv/poudriere/data/.m/freebsd_10-3x64-HEAD/ref/.p/pool
HAVE_COMPAT_IA32_KERN=YES OPSYS=FreeBSD
MASTERNAME=freebsd_10-3x64-HEAD
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=1003000
---End Environment---

---Begin OPTIONS List---
===> The following configuration options are available for 
php70-pdo_mysql-7.0.14:

 MYSQLND=on: Use MySQL Native Driver
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--
--with-pdo-mysql=mysqlnd --with-php-config=/usr/local/bin/php-config 
--prefix=/usr/local ${_LATE_CONFIGURE_ARGS}

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work TMPDIR="/tmp" 
SHELL=/bin/sh CONFIG_SHELL=/bin/sh 
AUTOCONF=/usr/local/bin/autoconf-2.69 
AUTOCONF_DIR=/usr/local/share/autoconf-2.69 
AUTOHEADER=/usr/local/bin/autoheader-2.69 
AUTOIFNAMES=/usr/local/bin/ifnames-2.69 
AUTOM4TE=/usr/local/bin/autom4te-2.69 
AUTORECONF=/usr/local/bin/autoreconf-2.69 
AUTOSCAN=/usr/local/bin/autoscan-2.69 
AUTOUPDATE=/usr/local/bin/autoupdate-2.69  AUTOCONF_VERSION=2.69 
CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144

--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work 
HOME=/wrkdirs/usr/ports/databases/php70-pdo_mysql/work TMPDIR="/tmp" 
NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes 
SHELL=/bin/sh NO_LINT=YES  AUTOCONF=/usr/local/bin/autoconf-2.69 
AUTOCONF_DIR=/usr/local/share/autoconf-2.69 
AUTOHEADER=/usr/local/bin/autoheader-2.69 
AUTOIFNAMES=/usr/local/bin/ifnames-2.69 
AUTOM4TE=/usr/local/bin/autom4te-2.69 
AUTORECONF=/usr/local/bin/autoreconf-2.69 
AUTOSCAN=/usr/local/bin/autoscan-2.69 
AUTOUPDATE=/usr/local/bin/autoupdate-2.69  AUTOCONF_VERSION=2.69 
PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"  CC="cc" 
CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"  CPP="cpp" 
CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++" 
CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing " 
MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555" 
BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m 
555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"

--End MAKE_ENV--

--PLIST_SUB--
PHP_EXT_DIR=20151012
OSREL=10.3
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""

Re: The ports collection has some serious issues

[Roger Marquis]

On Sun, 18 Dec 2016, Willem Jan Withagen wrote:

On 18-12-2016 16:00, John Marino wrote:

[please keep me CC'd, I can't respond easily if not]

I find that sort of strange... but that could be my feeling.


Given the hyperbole and intentionally misleading content of waay too
much of this thread, including its title, the only thing I find strange
is that anyone could take it seriously.


Like I said, it feels strange.


If you think that's strange you should check out the posts that
torpedo'd HardenedBSD's Reddit page.  Having seen this before in other
projects and knowing some of the sources you wouldn't be mislead by
following the money i.e., astroturf.  At least the FreeBSD project
doesn't utilize professional astroturfers advertising on sites like the
Philippines' Craigslist.  See also
.

Roger Marquis
___
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

[Willem Jan Withagen]

On 18-12-2016 16:00, John Marino wrote:

> [please keep me CC'd, I can't respond easily if not]

I find that sort of strange... but that could be my feeling.

Someone builds a tool, and then decides that it is not very useful to be
part of the community that he creates the tool for...

Like I said, it feels strange.
--WjW

___
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

[Dave Horsfall]

On Sun, 18 Dec 2016, John Marino wrote:

> > > 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.

I happen to know Peter as a friend; you don't.  He doesn't troll; you do.

And who is this "everyone", anyway?  Either enumerate them, or STFU.

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

[Matthew Seaman]

On 18/12/2016 14:18, Grzegorz Junka wrote:
> Isn't poudriere automatically saving the options file when building a
> new port with default options (i.e. when no options have been
> specified)? And also, aren't the selected options available in the
> resulted pkg file, so that synth could look them up there?

Poudriere will only save options settings if you run 'poudriere options
...' -- if you're trying to build a package and you've never set any
options for it, then poudriere will silently build using the default
options for that package.  Similarly if the maintainer adds or removes
options on a port where you already set some options, poudriere will
just quietly build using the default value of any new options.

On the other hand, if you do modify options, or if the default options
settings change in the ports, poudriere will recognise this the next
time you run a 'poudriere bulk ...' or similar and will add the packages
with changed options to the rebuild queue.

Yes, the resulting pkg contains information about the options settings.
You can see this in the --full or --raw output from pkg-info(8), but it
seems there is no flag to pkg-info(8) to print out just the options
settings.  To do that, use pkg-query(8):

# pkg query '%Ok %Ov' postfix
BDB off
CDB off
DOCS on
INST_BASE off
LDAP off
LDAP_SASL off
LMDB on
MYSQL off
NIS off
PCRE on
PGSQL off
SASL on
SASLKMIT off
SASLKRB5 off
SQLITE off
TEST off
TLS on

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[scratch65535]

 On 17 Dec 2016, at 20:47, Alphons van Werven
 wrote:
> 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.

I don't know what direction Fonz sees the project moving in [his
loss will be significant, and I personally wish he would
reconsider], but I've had a sense for some time that there's an
undercurrent of some kind moving us insensibly toward Linux and,
strangely, a mix of uncaringness and authoritarianism.  

I can't really quote specifics on my perception of a Linux-ward
drift because I haven't been keeping an evidence notebook.  But
for evidence of authoritarianism creeping in,  I offer the
imposition of the new pkg utility on all of us awhile back even
though it was still half-baked.  That came as qute a shock, at
least to me.  I didn't like it at all.   And now there seems to
be some psychological warfare going on over basic build tools.

I go back a ways with FreeBSD,  v1.1.3 or something like that. So
I'm not ready to bail, but I really, truly, no-kidding perceive a
drift toward incoherence that, unless reversed, will make FreeBSD
just another footnote in computing history, like Minix, 386BSD,
the UCSD P-system, and others that after a brief heyday ceased to
matter because their support base was hobby-oriented and
uncommitted, with neither a clear vision for the future nor even
a desire for one.
___
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

[John Marino]

Grzegorz Junka wrote:

On 17/12/2016 18:51, John Marino wrote:

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.


Isn't poudriere automatically saving the options file when building a
new port with default options (i.e. when no options have been
specified)? And also, aren't the selected options available in the
resulted pkg file, so that synth could look them up there?
Grzegorz


[please keep me CC'd, I can't respond easily if not]

Synth does look up package options.  It compares it with the currently 
options specifications and will obsolete the package if they don't match 
exactly.


Synth intentionally does not store option files.  It will use option 
files that are pre-created for it (the lack of stored options means "use 
the defaults").


The behavior is intentional and it results in synth rarely having to 
break a scan and stop and most people want this, but it just so happens 
that abi wanted the exact opposite behavior.  It's actually the first 
time I've heard somebody wanting the "explicitly save options" behavior 
because it's quite disruptive in practice. [1]


John

[1] I wonder how hard it would be for Synth to optionally create an 
saved options file (outside of the ports framework) when the package is 
successfully built.  It's likely possible (non-default behavior)


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

[Grzegorz Junka]

On 17/12/2016 18:51, John Marino wrote:

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.


Isn't poudriere automatically saving the options file when building a 
new port with default options (i.e. when no options have been 
specified)? And also, aren't the selected options available in the 
resulted pkg file, so that synth could look them up there?

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

[scrat]

On 12/18/16 02:24, John Marino wrote:


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



Jumping into the frying pan ( I like it hot ).

I like synth and I use it for all my AMD64 boxen.  The only thing that I 
have an issue with is when there are only a few packages that are being 
updated and it wants to build 100+.  Example:


These are the ports that would be built ([N]ew, [R]ebuild, [U]pgrade):
  U => x11/libXpm (3.5.11_4 => 3.5.12)
  U => audio/soundtouch (1.9.2_1 => 1.9.2_2)
  N => ports-mgmt/dialog4ports
  U => editors/vim-lite (8.0.0130 => 8.0.0134)

  R => mail/thunderbird
  R => x11/kde4
  R => x11/lumina
  R => x11/xorg
Total packages that would be built: 221

Yes I cut some of the ones to be rebuilt.  I don't know enough about the 
how, when and why that synth needs to rebuild all of those... I just 
except it and move on.   Synth has never left me with a broken system as 
some of the other package managers.


I have synth configured to use /usr/home/synth:

$ ls /usr/home/synth
build   logspkg.listports
distfiles   packagespkgbld.sh   svn-update-freebsd.sh

so everything is in /usr/home/synth.

Here is how I use it ( I have two scripts )

cat svn-update-freebsd.sh

#!/bin/sh -

prefix="/usr/home/source"
current="base/head"
stable="base/stable/11"
releng="base/releng/11.0"
release="base/release/11.0.0"
ports="ports/head"
branches="branches/2016Q4"
doc="doc/head"
source="${stable} ${releng} ${release} ${ports} ${branches} ${doc}"
for i in ${source} ; do
if [ -d "${prefix}/${i}" ]; then
svnlite update "${prefix}/${i}"
else
mkdir -vp "${prefix}/${i}"
svnlite co "https://svn.freebsd.org/${i}; "${prefix}/${i}"
fi
done
#mkdir -vp "${prefix}/quarterly/2016Q4"
#svnlite checkout "https://svn.freebsd.org/ports/branches/2016Q4 
${prefix}/quarterly/2106Q4"
rsync --verbose --archive --recursive --delete ${prefix}/${ports}/ 
/usr/home/synth/ports/


cat pkgbld.sh

#!/bin/sh -
synth just-build /usr/home/synth/pkg.list
synth rebuild-repository

A simple

#  cd /usr/home/synth && ./svn-update-freebsd.sh && ./pkgbld.sh;poweroff

works for me.

Synth is good and I highly recommend it.
___
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

[John Marino]

David wrote

On 12/16/2016 04:06 PM, John Marino wrote:

Starting with a clean system:
1) install synth from binary package from official freebsd builder (a
single package)


What about just building synth from ports? Then the OP have everything
built from ports.

--
David


In the example, the system is *clean*.  If you build from ports you 
immediately litter it with installed build dependencies.


The "real" process is just use the binary package that FreeBSD provides. 
 I was showing how to bootstrap it cleanly and the target audience is 
those that insist they were the ones to build it (which I assume is a 
small percentage of the overall audience).  There is zero advantage to 
building it yourself.


The other reasons is that all the build dependencies get generated as 
packages in a synth directory, so by avoiding Synth temporarily has the 
cost of having to potentially rebuild them all again later for other 
packages or rebuilding a new version of synth.  So it avoids unnecessary 
repeat work 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

[David Demelier]

On 12/16/2016 04:06 PM, John Marino wrote:

Starting with a clean system:
1) install synth from binary package from official freebsd builder (a 
single package)


What about just building synth from ports? Then the OP have everything 
built from ports.


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

[Bob Eager]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 18 Dec 2016 17:43:32 +1100
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.
> 
> > 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.

I agree. One of the criticisms levelled at portupgrade is that it needs
ruby. But to need Ada...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYVmsjAAoJECgXX9ms/Huo6NYH/1+t2KbHubACNbgD8+cnJGNQ
rFABzBnv5QgU1ypuNlTO1kYtwPmFtFXa1Oz/24tHygTXJKFoYhlyDAZGmwS12KIo
PtDkfgyjcv0/W1uWMZbZXB3N3IQXcJ1VOKLNHhKhP3IKEaUrFJhL6gIXcEs5ObiG
4ShLYZtyxNWAbhOP7dGyOaXY5wkkxXBntNmMko4+cRoNgHbHScufpJJT5fiRPPue
85XDhS9XVNbGbG+tcxLFcPaejtc/cn+MpkByqFWYknORsT1NCphmgs7t/NcY5yOB
rR+LTHh0oHVW3n3qV4pZIZ/zXrq78QYN6INVUtrDnRJ21nfjit0/N8fHhASYUhY=
=CnYc
-END PGP SIGNATURE-
___
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

[Thomas Mueller]

>From John Marino and my previous post:

> > 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.

I ran make all-depends-list from $PORTSDIR/ports-mgmt/synth.  Dependencies 
looked like packages I would need anyway.

I want to try to cross-compile Haiku and Linux toolchains (among other things).

I looked for synth in the online wiki.freebsd.org, found nothing, but did find 
portupgrade (no portmaster).

If FreeBSD users are to use synth, it needs to be in the documentation. 
Otherwise FreeBSD users will assume portupgrade or portmaster is the proper way 
to upgrade ports.

I would have thought there would be an Ada for ther platforms like PowerPC and 
(Ultra)Sparc.

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

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

Re: The ports collection has some serious issues

[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

[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

[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

[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

[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

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

[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

[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

[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

[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

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

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

Re: The ports collection has some serious issues

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

Re: The ports collection has some serious issues

[Hrant Dadivanyan]

> >
> > 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.

Hrant

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

-- 
Hrant Dadivanyan (aka Ran d'Adi)hrant(at)dadivanyan.net
/* "Feci quod potui, faciant meliora potentes." */   ran(at)psg.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 ports collection has some serious issues

[Grzegorz Junka]

On 16/12/2016 14:45, John Marino wrote:


DragonFly has switched to Synth from poudriere as it's primary package 
builder.  That means it builds entire repositories (25,000 packages) 
biweekly on multiple servers.  It's highly used which serves as 
continuous testing.  I also use it on FreeBSD to test updates to 
ports. In fact, anyone that updates ports should use either poudriere 
testport or synth test.  (Based on evidence, it's clear that some 
people whom I won't name publicly never use the QA checks before 
committing significant changes but that's getting sidetracked).


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


I think adding synth as the default builder in the FreeBSD Handbook and 
deprecating portmaster and portupgrade in the documentation would go a 
long way towards letting newcomers use the ports in the proper way 
(since they are not maintained anyway). They wouldn't need to be removed 
from ports for those hardcore users who are already used to using them. 
The current presence of those tools in the official Handbook makes them 
somehow the official way of upgrading ports in FreeBSD, even if it's the 
worst way of upgrading ports possible.

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

[Roger Marquis]

John Marino wrote:

From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, 
recommending a newer version of the port)


I'd consider that to be a bug.

So it's not a contradiction.  Ports that have a specific removal date must 
have EXPIRATION_DATE set.  If you say, well DEPRECATION implies removal, I'd 
agree, but it's at an indefinite time and I'd say that time would come when 
portmaster no longer works on the current ports tree. When that happens (and 
it probably will happen) then EXPIRATION can be set.


Non-standard uses of the term "deprecated" are problematic from a
usability perspective.  Since there is currently no deprecation messages
(apologies for the misunderstanding, I haven't used portmaster) at least
(TZ) add an install-time WARNING so we can avoid misleading potential
portmaster users (and related mailing lists threads/topics).

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

[John Marino]

On 12/16/2016 10:09, Roger Marquis wrote:

I never understood why people went ape- over it, unless they don't
understand what "deprecated without expiration" actually means.


Perhaps then this is the crux of the issue.  From my experience
"deprecated" means only that something will not appear in a future
version of the OS.  It implies nothing about the suitability of the
software itself.  "deprecated without expiration" is a contradiction.


From porters handbook, section 12.15:
"It is possible to set DEPRECATED without an EXPIRATION_DATE (for 
instance, recommending a newer version of the port), but the converse 
does not make any sense."


So it's not a contradiction.  Ports that have a specific removal date 
must have EXPIRATION_DATE set.  If you say, well DEPRECATION implies 
removal, I'd agree, but it's at an indefinite time and I'd say that time 
would come when portmaster no longer works on the current ports tree. 
When that happens (and it probably will happen) then EXPIRATION can be set.





If Torsten drops maintainership then some sort of "strong" warning
should come with that drop.  I would be satisfied with adding a
descriptive DEPRECATED message myself.


TZ or no TZ we should drop the deprecation notice until it has an
expiration date and clarify the warning terms (ASAP).  At least that
way, when a thread like this comes up in the future, the only response
needed would be a pointer to the install message.


Which notice should we drop?  There's no DEPRECATION set now.  There's 
no warning set.  portmaster is not marked as "deprecated".


And as the handbook points out: You can't have EXPIRATION without 
DEPRECATED, but it's perfectly legal to have the reverse.  It's 
documented clearly.


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

[Roger Marquis]

It is just semantics.


That may be but as illustrated in this thread people maintain
unreasonable expectations of portmaster which they often blame on the
ports subsystem.


I never understood why people went ape- over it, unless they don't
understand what "deprecated without expiration" actually means.


Perhaps then this is the crux of the issue.  From my experience
"deprecated" means only that something will not appear in a future
version of the OS.  It implies nothing about the suitability of the
software itself.  "deprecated without expiration" is a contradiction.

If Torsten drops maintainership then some sort of "strong" warning should 
come with that drop.  I would be satisfied with adding a descriptive 
DEPRECATED message myself.


TZ or no TZ we should drop the deprecation notice until it has an
expiration date and clarify the warning terms (ASAP).  At least that
way, when a thread like this comes up in the future, the only response
needed would be a pointer to the install message.

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"

The ports collection has some serious issues

[John Marino]

Roger Marquis wrote

It is every week.  Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. Let's
stop making excuses for portmaster.  It is what it is and we've had years to
evaluate it.


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.


It is just semantics.
A "deprecated" message is just a warning.  Maybe even a "strong" 
warning.  By itself, it means nothing more than that.  Since the 
beginning, portmaster was not going to be removed, it was just going to 
carry this warning to alert users.


What you propose is what has always been proposed.  I never understood 
why people went ape- over it, unless they don't understand what 
"deprecated without expiration" actually means.  I just assumed that 
having such a warning was a scarlet letter and fans of portmaster didn't 
want the reputation defamed.


If Torsten drops maintainership then some sort of "strong" warning 
should come with that drop.  I would be satisfied with adding a 
descriptive DEPRECATED message myself.


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

[Roger Marquis]

It is every week.  Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. Let's 
stop making excuses for portmaster.  It is what it is and we've had years to 
evaluate it.


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

[John Marino]

From Kevin Oberman:

Just to add another voice of those who use portmaster on a regular basis. I
moved to portmaster about seven years ago and have has very few issues with
it. I have had issues building ports from time to time, but it's been a
long time since i hit one that was not a problem with the port... often
related to the options I use. I like that it has no dependencies. I like
that it is very stable. There are things I would like to see changed, but I
would be very upset to lose it. Since it is stable, the only way I would
lose it is if the underlying port structure changed in a way that required
work on it.

Saying that synth and poudriere are replacements for portmaster/portupgrade
simply indicate lack of familiarity with my (and others) use cases. I have
used synth and it is excellent, but not on my development system where
everything is built from source and I hope always will be. I have found
portupgrade too fragile for the reasons mentioned.  I had to clean up a
mangled database once too often. (Yes, it is a flat text db, so it can be
fixed manually, but it is NOT fun!)


"but not on my development system where everything is built from source 
and I hope always will be"


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.


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

[John Marino]

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.



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.


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.



If I was interested in package builders, I would spend some time
helping to test them. Since my interests related to FreeBSD is on
other things / tools / whatever, I spend my "FreeBSD time" on those
other things instead.


DragonFly has switched to Synth from poudriere as it's primary package 
builder.  That means it builds entire repositories (25,000 packages) 
biweekly on multiple servers.  It's highly used which serves as 
continuous testing.  I also use it on FreeBSD to test updates to ports. 
In fact, anyone that updates ports should use either poudriere testport 
or synth test.  (Based on evidence, it's clear that some people whom I 
won't name publicly never use the QA checks before committing 
significant changes but that's getting sidetracked).


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


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

[Andrea Venturoli]

On 12/16/16 07:42, Torfinn Ingolfsen wrote:


FWIW, I'm a happy portupgrade user.


Me too.

I just frequently run into a bug: when icu is updated, somehow the old 
libraries are not saved and all ports depending on icu break.

Now I know that I should take care with that single port.

Also, I wish I would be to be able to "portupgrade" a jail, i.e. running 
portupgrade in base and update the ports inside jails, without the need 
to install portupgrade (and ruby and every other dependency) in the jail.




That said, I've been considering the move to poudriere, but that's a low 
priority task.


 bye
av.

___
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

[Torsten Zuehlsdorff]

On 15.12.2016 18:43, Miroslav Lachman wrote:

John Marino wrote on 2016/12/15 17:46:


[1] I've got it on my todo list to provide a new method that would
eliminate the "my builder just rebuilt 150 packages, but pkg(8) only
upgraded 2 packages" issue that some users don't want to see.  It's a
lot more complicated than the conservative yet bulletproof approach
currently used by poudriere and synth.


This is interesting case - we are running own Poudriere repo and I am
fine with it. But I am a bit nervous when I know 150 packages was
rebuilt and just 2 upgraded by pkg. In this case I want pkg to update
(reinstall) all of them.
If something changed so that 150 packages must be rebuilt why pkg
doesn't reinstall them? Isn't it the possible place for problems after
upgrade?


Not really. I found the following explanation from babt about this behavior:
https://lists.freebsd.org/pipermail/freebsd-ports/2015-January/097569.html

Since its from last year, it is maybe outdated. But if this issue still 
stands, its worth addressing it.


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

[Dave Cottlehuber]

On Mon, 12 Dec 2016, at 17:20, Julian Elischer wrote:
> > Have you considered using things like poudriere that would allow you to 
> > build
> > your own repository with your own set of packages and options.
> >
> > You will benefit:
> > - ability to use pkg for your upgrades
> > - ability to use customize your packages
> > - safe rebuild process (in case of broken ABI)
> >
> > Best regards,
> > Bapt
> I'm actually slowly moving to this if I can work out how to specify my 
> own chroot image, and a few other things I need to tweak. (my own sets 
> of patches to add).

Hi Julian,

I've been doing this with poudriere + pkg + git for a couple of years
now very happily, using a lagging ports checkout (similar to the
quarterly branch but taken at our convenience), and git rebasing our
custom patches so they "float" up to the top. We're using it at
iwantmyname.com now as well.

The guts of it is:

- use poudriere as usual but with a git-backed /usr/ports
- store custom patches in /usr/ports and push to
https://github.com/ideegeo/ports/ until they get committed in FreeBSD
ports tree
- git rebase periodically to pull in shiny bits from
git://github.com/freebsd/freebsd-ports master branch
- ansible pkg triggers a poudriere run whenever we add a new package to
the list
- these are made available via our pkg repo to our servers
- in practice, ansible is used to set up the whole stuff from scratch
including letsencrypt certs for the https://pkg.example.org/ but these
are the pre-automation steps I started with.

Here are the raw notes from our wiki and that should be sufficient for
you to try this out on a test VM somewhere.  I assume I've forgotten
stuff or made errors but promise to blog it over Christmas with a longer
explanation.

https://gist.github.com/dch/ec2693c051c66dcd2f17b30fc575a910

BTW I'm not exactly sure what you mean about a custom chroot image, but
I imagine you can fiddle with the poudriere base in
zroot/poudriere/jails/11_amd64 to your heart's content and it will be
used during the build.

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

[Kevin Oberman]

On Thu, Dec 15, 2016 at 9:42 PM, Peter Jeremy  wrote:

> On 2016-Dec-15 19:31:22 +0100, 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.
>
> I don't know about never - I think I managed to get it into a dependency
> loop once - but I've never had any issues that I could not resolve or
> that would entice me to look at an alternative.
>
> >(But portupgrade could at times be an utter mess,
> >I never looked back after switching to portmaster
> >many years ago.)
>
> Likewise, portupgrade would explode and shower my system with bits of
> corrupt database to often for comfort.  At least part of that was caused
> by portupgrade depending on quite a few other ports and getting confused
> when it updated things whilst it was using them.
>
> >And I'm not at all interested in running poudriere
> >or synth, thank you.
>
> Interestingly, the most vocal proponent of deleting portmaster and
> portupgrade is the author/maintainer of synch.
>
> --
> Peter Jeremy
>

Just to add another voice of those who use portmaster on a regular basis. I
moved to portmaster about seven years ago and have has very few issues with
it. I have had issues building ports from time to time, but it's been a
long time since i hit one that was not a problem with the port... often
related to the options I use. I like that it has no dependencies. I like
that it is very stable. There are things I would like to see changed, but I
would be very upset to lose it. Since it is stable, the only way I would
lose it is if the underlying port structure changed in a way that required
work on it.

Saying that synth and poudriere are replacements for portmaster/portupgrade
simply indicate lack of familiarity with my (and others) use cases. I have
used synth and it is excellent, but not on my development system where
everything is built from source and I hope always will be. I have found
portupgrade too fragile for the reasons mentioned.  I had to clean up a
mangled database once too often. (Yes, it is a flat text db, so it can be
fixed manually, but it is NOT fun!)
--
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 ports collection has some serious issues

[Torfinn Ingolfsen]

On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy  wrote:
> On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote:
>>On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote:
>
>>(But portupgrade could at times be an utter mess,
>>I never looked back after switching to portmaster
>>many years ago.)
>
> Likewise, portupgrade would explode and shower my system with bits of
> corrupt database to often for comfort.  At least part of that was caused
> by portupgrade depending on quite a few other ports and getting confused
> when it updated things whilst it was using them.
>

FWIW, I'm a happy portupgrade user.
Yes - sometimes it breaks, but it is quite rare, and I am able to fix
the breakage when it happens.
So for me it is "good enough".


>>And I'm not at all interested in running poudriere
>>or synth, thank you.
>
> Interestingly, the most vocal proponent of deleting portmaster and
> portupgrade is the author/maintainer of synch.

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.
If I was interested in package builders, I would spend some time
helping to test them. Since my interests related to FreeBSD is on
other things / tools / whatever, I spend my "FreeBSD time" on those
other things instead.

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

[Peter Jeremy]

On 2016-Dec-15 19:31:22 +0100, 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.

I don't know about never - I think I managed to get it into a dependency
loop once - but I've never had any issues that I could not resolve or
that would entice me to look at an alternative.

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

Likewise, portupgrade would explode and shower my system with bits of
corrupt database to often for comfort.  At least part of that was caused
by portupgrade depending on quite a few other ports and getting confused
when it updated things whilst it was using them.

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

Interestingly, the most vocal proponent of deleting portmaster and
portupgrade is the author/maintainer of synch.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: The ports collection has some serious issues

[Daniil Berendeev]

> Here, it doesn't look like that. Don't forget that /usr/ports/distfiles
> accumulates old versions and must be manually cleaned out from time to
> time.  portmaster has a couple of options to remove distfiles that are
> not needed.
> 
> % du -hd0 /usr/ports
> 8.1G/usr/ports
> % du -hd0 /usr/ports/distfiles
> 6.5G/usr/ports/distfiles
> 
> After copying that to /tmp and deleting distfiles entirely:
> 
> % du -hd0 /tmp/usr/ports
> 1.4G/tmp/usr/ports

Well, I know that, I were trying to tell that portsnap(8) is fetching
HEAD by default and I didn't find any way to change that behavior. So
the only way to pick another branch would be fetching the entire svn
repository. I need it for development purposes also, so anyway I'd have
to do that.

But the size of the svn repository causes pure pain. Subversion is not
intended for development style that requires keeping lots of branches
and tags. Everyone knows that. At the moment, the repository takes
~/> du -h ports-fbsdsvn/
 42Gports-fbsdsvn/

In git, Mercurial, bazaar, well, any modern version control system you
can create tons of branches, tags without wasting space or time.

-- 
Cheers~

PGP key fingerprint:
07B3 2177 3E27 BF41 DC65  CC95 BDA8 88F1 E9F9 CEEF

You can retrieve my public key at pgp.mit.edu.
___
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

[Michelle Sullivan]

Matthieu Volat wrote:

On Thu, 15 Dec 2016 19:31:22 +0100
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.


It seems that if people happy with portmaster keep silent, others will assume 
it's okay to try to dismiss it;


Yup


  so here am I, happy with portmaster.


Don't worry, the people that have the power will dismiss it when they 
deem you need to "upgrade" to using synth or poudreire... oh and don't 
worry they'll remove distfiles and the previous 4 versions of the 
distfiles so that you can't keep your own local copy running, especially 
if you publish how to use it yourself.




I could switch to something else that is feature wise similar; but if it would 
not written in some quasi-obselete/niche/hipster programing language or involve 
admin/config tasks like creating repos.

Until a challenger appears, I'm just going to use and recommend portmaster.


Same.

Regards,

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

[Mark Millard]

John Marino freebsd.contact at marino.st on Thu Dec 15 16:46:54
UTC 2016 wrote:

> For i386 and amd64 users, synth does not require more resources than 
> portmaster.  People on those platforms can't use "resources" as a reason 
> not to use Synth.  From what I can tell, portmaster people hate what 
> they consider unnecessary rebuilds which both poudriere and synth 
> (currently [1]) do, but it's this avoidance of rebuilds that cause all 
> their problems.

Also on Thu Dec 15 16:00:47 UTC 2016:

> Anybody with a machine that doesn't have a resources to run poudriere or 
> synth should not be building packages on that machine.  Veterans have 
> the option to use portmaster in a case like that, but it's not something 
> that should be suggested to newbies.

Note: My FreeBSD usage is not from any of the main families of usage. Do
  not think that I expect things to be biased for my use. My kind
  of context may well be implicitly not intended to be covered by the
  above.


I wonder if build tool recommendations need some breakout by
user categories rather than one grand overall recommendation.
This might be just a note of "no specific recommendation" for
some category(s).

I use my context below as a potential example.

I primarily experiment with self hosting FreeBSD activities on powerpc64,
powerpc, armv6/armv7, and aarch64, reporting issues that I find. For the
powerpc family this has focused on fairly modern clang usage for
buildworld and buildkernel -- as well as building ports. This tends to
fit me with "developer" and less with "user" in some respects.

If synth was buildable and usable on powerpc64, powerpc, armv6/armv7, 
and aarch64 I likely would have tried it. (I do not want to be using
different self-hosting techniques per TARGET_ARCH but instead use
one set of techniques on all.)

Building synth would take up more time and space than portmaster but
I could have tolerated such. For the SD card contexts I tend to
have an SSD for the root file system. This likely is uncommon. Only
the old powerpc's have fewer than 4 cores/processors supported by
FreeBSD: one armv7 has 8 but FreeBSD supports only 4. buildworld with
-j 4 or so does take a long time on the armv7 machines (for example).
Of course there are large differences in performance compared to modern
amd64's.

When I tried portupgrade over a time I had problems with ruby in these
environments. (amd64 went okay.) I eventually backed off, figuring I'd
retry after some significant time in case they were temporary issues.

Other than backups/recovery media I have one powerpc64 SSD for experiments,
one powerpc SSD, one armv7 SSD (and an SD card) per single board computer
type, and the same for the one aarch64 single board computer. Definitely
not build-once/distribute-many generally. (But the armv7 context could do
a little of that as I'm currently structuring things.)

After "pkg autoremove" "portmaster --list-origins" lists 20-30 or so
ports in each case. Before the autoremove "pkg info | wc" is under 100
as I remember. I sometimes have patches to ports involved when someone
asks me to test such for something that I've reported. And because of
binutils problems for powerpc64 I use older versions from svn in the
contexts that I deal with targeting powerpc64's (that includes the
devel/powerpc64-binutils slave port). For a time devel/powerpc64-gcc
could not finish buildworld unless I used an older vintage from svn.

I really do use devel/powerpc64-gcc and devel/powerpc64-binutils and
devel/powerpc64-xtoolchain-gcc on a powerpc64: a "self hosted cross
build" of sorts. Getting devel/powerpc64-gcc installed on a powerpc64
requires a work-around because it is not a true cross-build and
some things are not the same if the target architecture is not
distinct: I'm operating outside the intended usage model. The work
around involves copying/moving some files to the right place/name
in the staging area so that installation can find them and complete.

[I also use amd64 FreeBSD under virtualbox in another operating
system. This context has more to it but is still likely less than
is typical.]

[Ignoring amd64:] If I had been able to use synth on the variety of
machines it would appear that the contribution of my time preferences
might have eventually stopped my use. (Not the number of ports
rebuilt as such but the systematic time spent.) "Might" because for
my context it is not obvious up front what my judgement might be
after a trail period.

I'm not sure what I would have done about issues like
devel/powerpc64-gcc being built and installed on a powerpc64
machine and needing a work around. Or testing patches for ports.
I did not try to figure it out since I since I discovered
synth was not an option first.

I configure to avoid "disk" space issues generally (SSD root
filesystems normally, with plenty of space).

RAM varies from 1G to 2G Bytes over the armv7's, aarch64, and some
powerpc's, but for powerpc64 there is more RAM: 8G, 12G, or 16G

Re: The ports collection has some serious issues

[Matthieu Volat]

On Thu, 15 Dec 2016 19:31:22 +0100
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.
> 

It seems that if people happy with portmaster keep silent, others will assume 
it's okay to try to dismiss it; so here am I, happy with portmaster.

I could switch to something else that is feature wise similar; but if it would 
not written in some quasi-obselete/niche/hipster programing language or involve 
admin/config tasks like creating repos.

Until a challenger appears, I'm just going to use and recommend portmaster.

Happy bsding everybody

-- Matthieu


pgplStNvzBqaD.pgp
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[list-freebsd-ports]

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"

Re: The ports collection has some serious issues

[George Mitchell]

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

___
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

[Miroslav Lachman]

John Marino wrote on 2016/12/15 17:46:


[1] I've got it on my todo list to provide a new method that would
eliminate the "my builder just rebuilt 150 packages, but pkg(8) only
upgraded 2 packages" issue that some users don't want to see.  It's a
lot more complicated than the conservative yet bulletproof approach
currently used by poudriere and synth.


This is interesting case - we are running own Poudriere repo and I am 
fine with it. But I am a bit nervous when I know 150 packages was 
rebuilt and just 2 upgraded by pkg. In this case I want pkg to update 
(reinstall) all of them.
If something changed so that 150 packages must be rebuilt why pkg 
doesn't reinstall them? Isn't it the possible place for problems after 
upgrade?


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

[Iblis Lin]

I want to talk about another issue: the testing of ports framework

We usually test our ports via poudriere or synth. We have a greate ports
framework to help us build software, and we only need to write a few
lines of code to leveage it. But ...  where is the testing of the framework ?
Those code under Mk/* is quite complex nowaday, and the requirement is
keeping changing (for example, more and more new languages appear,
helpers need to be added into ports framework). This will be a big barrier
for maintenance. Is time to build a next generation framework?

I think about this issue for a few weeks already, but still not get a good
answer. I only sorted out some principles and want to hear more
feedback:

1) Select a modern scripting language
Lots of testing methodology implemented in those languages.
Most of them are high-level. The cost of maintenance (hopefully)
reduce. So, I think this is a good starting point.

2) Not to abandon tons of Makfile

3) Not to introduce any new dependency for a end user

Just my imagination: In order to keep (2) and (3), I will use Python to
build a system doing Makfile code generation. The ports framework
managers and porters just write some Python function and testing code, then
generate a proper tested and stable Makefiles for users.

-- 
Iblis Lin
林峻頤
___
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

[Torsten Zuehlsdorff]

On 15.12.2016 17:46, John Marino wrote:

On 12/15/2016 10:31, Torsten Zuehlsdorff wrote:

On 15.12.2016 17:00, John Marino wrote:

It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement.
portmaster was added 2006 and the portstree startet in 1994.


Can you agree that if you combine both this list and issues that arise
on the FreeBSD forums that portmaster users talk about problems
frequently?


Yes, of course. I wasn't serious with this point and just want to 
degrade a little of the emotion to get back to a more technical and 
solvable level.



I could. My colleague did some of them. :D Even i generate some of them.


As a side discussion I would like to know what they are and if they are
valid for Synth as well.


Good question. I will ask my colleague to check; hopefully he does it also.


I see recommendations for poudriere or synth, but not for portmaster.
And i give them too.


Unfortunately portmaster get a lot of positive press on the forums.


Okay, that is just the opposite of the mailinglist. For bugzilla we have 
the helpful team around koops, which adjust the PRs. Maybe we should 
install something like that for the forum? Or just print a warning 
whenever portmaster is used (which would be much easier). We even can 
automatically link the word portmaster to an website, which gives more 
information and some warning.



Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a
commit which than breaks portmaster even after very good testing. And
that make me even more cautious. But also i'm not allowed to change the
code or do changes by myself, so its no surprise its very hard and i
considered to drop my maintainer line multiple times. Thats just beside
that the code is not written in a way which supports testing. So there
is a very big risk in every change. I started to rewrite it in an
private repo, but since it works (i could close many PRs) it really is
at the bottom of my list.


Interesting, but not surprising.  I know it was claimed to negate my
good point that such a piece of software needs a maintainer, but it had
to be somebody with deep level knowledge with both the capability and
*authority* to make the changes.

So now users think it's maintained and have a false confidence in it.
But with your name on it, I can't push for it to be marked "deprecated"
(with no expiration, that's important) anymore.  It's a loophole.


A breakable loophole. Since i figured out, that a complete rewrite would 
be a better solution, than the permanent danger of an very hard to test 
software, we can drop my name from it.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use,
but they can configure it like the need and without the pressure on
their own server. Maybe we need something like this to make it easier to
abandon portmaster.


For i386 and amd64 users, synth does not require more resources than
portmaster.  People on those platforms can't use "resources" as a reason
not to use Synth.  From what I can tell, portmaster people hate what
they consider unnecessary rebuilds which both poudriere and synth
(currently [1]) do, but it's this avoidance of rebuilds that cause all
their problems.

So providing them a poudriere service wouldn't solve that "problem" for
them.


It does. Since they are not aware of the "unnecessary" rebuilds, its no 
"problem" anymore.  If you have to watch rebuilding 150 ports just for 
an update of 2 ports, its a complete different story. If pkg only update 
2 ports and you can't see the work behind them, everything is fine. Its 
a little bit psychological.


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

[John Marino]

On 12/15/2016 10:31, Torsten Zuehlsdorff wrote:

On 15.12.2016 17:00, John Marino wrote:

It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement.
portmaster was added 2006 and the portstree startet in 1994.


Can you agree that if you combine both this list and issues that arise 
on the FreeBSD forums that portmaster users talk about problems 
frequently?  Does it matter if it's weekly or biweekly?  It seems to 
happen all the time on the forums, but I'm not going scan them to prove 
an exact frequency.





I could. My colleague did some of them. :D Even i generate some of them.



As a side discussion I would like to know what they are and if they are 
valid for Synth as well.



I see recommendations for poudriere or synth, but not for portmaster.
And i give them too.


Unfortunately portmaster get a lot of positive press on the forums.




Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a
commit which than breaks portmaster even after very good testing. And
that make me even more cautious. But also i'm not allowed to change the
code or do changes by myself, so its no surprise its very hard and i
considered to drop my maintainer line multiple times. Thats just beside
that the code is not written in a way which supports testing. So there
is a very big risk in every change. I started to rewrite it in an
private repo, but since it works (i could close many PRs) it really is
at the bottom of my list.


Interesting, but not surprising.  I know it was claimed to negate my 
good point that such a piece of software needs a maintainer, but it had 
to be somebody with deep level knowledge with both the capability and 
*authority* to make the changes.


So now users think it's maintained and have a false confidence in it. 
But with your name on it, I can't push for it to be marked "deprecated" 
(with no expiration, that's important) anymore.  It's a loophole.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use,
but they can configure it like the need and without the pressure on
their own server. Maybe we need something like this to make it easier to
abandon portmaster.


For i386 and amd64 users, synth does not require more resources than 
portmaster.  People on those platforms can't use "resources" as a reason 
not to use Synth.  From what I can tell, portmaster people hate what 
they consider unnecessary rebuilds which both poudriere and synth 
(currently [1]) do, but it's this avoidance of rebuilds that cause all 
their problems.


So providing them a poudriere service wouldn't solve that "problem" for 
them.


John

[1] I've got it on my todo list to provide a new method that would 
eliminate the "my builder just rebuilt 150 packages, but pkg(8) only 
upgraded 2 packages" issue that some users don't want to see.  It's a 
lot more complicated than the conservative yet bulletproof approach 
currently used by poudriere and synth.



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

[Torsten Zuehlsdorff]

On 15.12.2016 17:00, John Marino wrote:

On 12/15/2016 09:49, Torsten Zuehlsdorff wrote:

On 15.12.2016 16:29, John Marino 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.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or
miss-understanding of portmaster.


It is every week.  Consider the FreeBSD forums as well.


No, it isn't. Lets check the history. This is just a general statement. 
portmaster was added 2006 and the portstree startet in 1994.


Yes, there are emotions in discussions and they are really needed to 
drive things, but we need to ensure to drive in the right direction.



"misuse" and "misunderstanding" failures are attributed to the tool.
Let's stop making excuses for portmaster.  It is what it is and we've
had years to evaluate it.


I'm with you at this point. portmaster is incredible complex and hard to 
understand. Therefore it is easy to misue or to misunderstand.



With an argument like this you can also state there is every week a
falsely accuse, because of poudriere. This would also be true (and is).


I couldn't state that accurately.  I can't recall any misuse reports
(and I can't come up with a feasible case in my head right now)


I could. My colleague did some of them. :D Even i generate some of them.


The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the
freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate
disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes,
of course all three are code repositories. But one of them is a
distributed repository and the other two are not. The differences are
huge.
Of course it also depends on your usage. I personally (means "heavily
subjective) find git more than annoying. It lacks very important
features (user management), is hard to use in automatic environments and
make easy things (rename/delete branches) very hard. Other people really
like all of this. It depends.

So maybe the accusers just use the wrong tool?


The point is that you wouldn't start a new project with cvs.  You may or
may not transfer an existing project from cvs, but you're letting cvs
die by attribution.

The same should be for portmaster.  Some users will never see the light.
 Let them suffer by their own hand.  But for Pete's sake, don't
recommend it to new users.  That's not doing them any kind of service.


I see recommendations for poudriere or synth, but not for portmaster. 
And i give them too.


But both are tools which are not feasible for every situation. I often 
have a hard time to get them their space they need to make things 
better. So it would be a good idea under which circumstances portmaster 
is a good choice and whenever it is not.



Portmaster is not maintained.  Since you put your name on it, you've
made not a single commit to the repository, much less a new release. Yet
there are PRs on it.


No excuses here. You are right, but its another store. I approved a 
commit which than breaks portmaster even after very good testing. And 
that make me even more cautious. But also i'm not allowed to change the 
code or do changes by myself, so its no surprise its very hard and i 
considered to drop my maintainer line multiple times. Thats just beside 
that the code is not written in a way which supports testing. So there 
is a very big risk in every change. I started to rewrite it in an 
private repo, but since it works (i could close many PRs) it really is 
at the bottom of my list.



Please, can we somehow discourage new people from starting on it?
Anybody with a machine that doesn't have a resources to run poudriere or
synth should not be building packages on that machine.


I provide a poudriere server for my customers. Its not to nice to use, 
but they can configure it like the 

Re: The ports collection has some serious issues

[Warren Block]

On Thu, 15 Dec 2016, RW via freebsd-ports wrote:


On Thu, 15 Dec 2016 07:40:46 -0700 (MST)
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.  Except maybe portupgrade, which has legacy
problems like poor default options.


That's a very minor issue, and an absurd excuse to rule-out portupgrade.


I didn't rule it out.  Portupgrade gets some of the defaults wrong, like 
not running all the 'make config' steps first.  That's a legacy issue 
because if the default changes, it could conceivably cause problems for 
existing users.  Beyond that, other than a dependency on Ruby, 
portupgrade at least exists in the same space as portmaster.

___
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

[John Marino]

On 12/15/2016 09:49, Torsten Zuehlsdorff wrote:

On 15.12.2016 16:29, John Marino 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.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or
miss-understanding of portmaster.


It is every week.  Consider the FreeBSD forums as well.
"misuse" and "misunderstanding" failures are attributed to the tool. 
Let's stop making excuses for portmaster.  It is what it is and we've 
had years to evaluate it.



With an argument like this you can also state there is every week a
falsely accuse, because of poudriere. This would also be true (and is).


I couldn't state that accurately.  I can't recall any misuse reports 
(and I can't come up with a feasible case in my head right now)






The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the
freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes,
of course all three are code repositories. But one of them is a
distributed repository and the other two are not. The differences are huge.
Of course it also depends on your usage. I personally (means "heavily
subjective) find git more than annoying. It lacks very important
features (user management), is hard to use in automatic environments and
make easy things (rename/delete branches) very hard. Other people really
like all of this. It depends.

So maybe the accusers just use the wrong tool?


The point is that you wouldn't start a new project with cvs.  You may or 
may not transfer an existing project from cvs, but you're letting cvs 
die by attribution.


The same should be for portmaster.  Some users will never see the light. 
 Let them suffer by their own hand.  But for Pete's sake, don't 
recommend it to new users.  That's not doing them any kind of service.


Portmaster is not maintained.  Since you put your name on it, you've 
made not a single commit to the repository, much less a new release. 
Yet there are PRs on it.


Please, can we somehow discourage new people from starting on it? 
Anybody with a machine that doesn't have a resources to run poudriere or 
synth should not be building packages on that machine.  Veterans have 
the option to use portmaster in a case like that, but it's not something 
that should be suggested to newbies.  Now the discussion is sidetracked, 
but really nothing has improved since I tried to get a warning added to 
portmaster months ago.


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

[RW via freebsd-ports]

On Thu, 15 Dec 2016 07:40:46 -0700 (MST)
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.  Except maybe portupgrade, which has legacy 
> problems like poor default options.

That's a very minor issue, and an absurd excuse to rule-out portupgrade.
___
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

[Torsten Zuehlsdorff]

On 15.12.2016 16:29, John Marino 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.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being
broken but the accuser is the only one with the problem.  What do they
all have in common?  They are portmaster users.  I'll iterate, saying
"portmaster works" means applying a very generous definition of "works".


Not really, no. Its not every week and often there is a misuse or 
miss-understanding of portmaster.


With an argument like this you can also state there is every week a 
falsely accuse, because of poudriere. This would also be true (and is).



The recommended replacements are ports-mgmt/synth and
ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use
but they
do so in clean chrooted environments, and rebuild everything that's
required
to keep a consistent ABI. Synth is more designed for a single live
system
like a desktop or a single server, whereas poudriere is what the freebsd
package build clusters use and is more designed for that type of
usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.


I have a hard time to see git in this line. Its the way you use it. Yes, 
of course all three are code repositories. But one of them is a 
distributed repository and the other two are not. The differences are huge.
Of course it also depends on your usage. I personally (means "heavily 
subjective) find git more than annoying. It lacks very important 
features (user management), is hard to use in automatic environments and 
make easy things (rename/delete branches) very hard. Other people really 
like all of this. It depends.


So maybe the accusers just use the wrong tool?

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"

The ports collection has some serious issues

[John Marino]

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.  Except maybe portupgrade, which has legacy
problems like poor default options.


Every single week, somebody falsely accuses the ports tree of being 
broken but the accuser is the only one with the problem.  What do they 
all have in common?  They are portmaster users.  I'll iterate, saying 
"portmaster works" means applying a very generous definition of "works".




The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere.
These build an entire package repository that the pkg tool can use but they
do so in clean chrooted environments, and rebuild everything that's required
to keep a consistent ABI. Synth is more designed for a single live system
like a desktop or a single server, whereas poudriere is what the freebsd
package build clusters use and is more designed for that type of usage. Worth
taking a look.


These are package builders.  Technically preferable, given adequate disk
space and memory, but not equivalent to portmaster.


It's like saying git and svn are not equivalent to cvs.




It's a shame the handbook hasn't been updated to give this information.


Which information, in particular?  A section on Poudriere was submitted,
and I spent a fair amount of time editing it and getting it in there.
As far as Synth or other information, I'm not aware of any pending
Handbook or other documentation submissions.


for starters:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214679

Previous PRs indicated that recommendations for portmaster and 
portupgrade were to be removed, but so far this PR has stalled.


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

[Warren Block]

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.  Except maybe portupgrade, which has legacy 
problems like poor default options.


The recommended replacements are ports-mgmt/synth and ports-mgmt/poudriere. 
These build an entire package repository that the pkg tool can use but they 
do so in clean chrooted environments, and rebuild everything that's required 
to keep a consistent ABI. Synth is more designed for a single live system 
like a desktop or a single server, whereas poudriere is what the freebsd 
package build clusters use and is more designed for that type of usage. Worth 
taking a look.


These are package builders.  Technically preferable, given adequate disk 
space and memory, but not equivalent to portmaster.



It's a shame the handbook hasn't been updated to give this information.


Which information, in particular?  A section on Poudriere was submitted, 
and I spent a fair amount of time editing it and getting it in there.
As far as Synth or other information, I'm not aware of any pending 
Handbook or other documentation submissions.

___
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

[Warren Block]

On Thu, 8 Dec 2016, Daniil Berendeev wrote:


5) svn repository.
I don't want to spark a holy war and I don't belong to those type of
people who are always obsessed that something isn't done in their way.
But guys, svn is not a good tool for ports. Just for one reason,
actually (as for me, I could tolerate anything else, but not this one)
-- size. The size of repository is 20G+ and growing. I don't want to
pull 20G+ in /usr/ports just because I need to use ports. It's just
sick. The repository is so big because, as all ya know, svn is expensive
in branch operations. Since you've began to do those 2xxxQx branches the
size of the repository began to grow rapidly. It's inefficient and
uncomfortable. For such a work something like git or mercurial should be
used, they'd fit in 3-4G.


Here, it doesn't look like that. Don't forget that /usr/ports/distfiles 
accumulates old versions and must be manually cleaned out from time to 
time.  portmaster has a couple of options to remove distfiles that are 
not needed.


% du -hd0 /usr/ports
8.1G/usr/ports
% du -hd0 /usr/ports/distfiles
6.5G/usr/ports/distfiles

After copying that to /tmp and deleting distfiles entirely:

% du -hd0 /tmp/usr/ports
1.4G/tmp/usr/ports

Deleting /usr/ports/distfiles entirely is something I avoid because it 
seems that just when an urgent rebuild is needed, a distfile will be 
unfetchable. The portmaster options can keep distfiles only for 
currently installed ports, or current distfiles for any port, whether 
installed or not.

___
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

[Shane Ambler]

On 12/12/2016 23:14, scratch65...@att.net wrote:

[Default] On Mon, 12 Dec 2016 17:01:33 +1030, Shane Ambler
 wrote:



The quarterly ports has been setup for a couple of years but doesn't
seem to be documented well, or it just isn't obvious to find. You can
use svn to checkout a stable branch by specifying a branch name, such as
ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
use the quarterly ports by changing the pkg repo URL from
pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly


That's interesting.  The ones that break on me are the ones I get
from portsnap.  Does portsnap tap quarterly or something else?


Pretty sure portsnap gets snapshots from HEAD. Don't see a way to set
quarterly for it, so svn would be needed to get a quarterly ports tree.

It would mostly be a matter of timing, a snapshot is made for portsnap 
and a pkg build is started. By the time the pkg repo is built (a day? 
two?) a new snapshot would be in use by portsnap so it would never be in 
sync with the pkg repo.


It might be worth changing defaults to use quarterly for both portsnap 
and pkg. An average user shouldn't have issues to only getting new 
versions every three months, for those that want to stay on the cutting 
edge a few settings can be changed to use HEAD and/or latest.


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

[Shane Ambler]

On 13/12/2016 06:01, Julian H. Stacey wrote:

I would say this rarely happens with the default setup, the more port
options you change the more likely it is something will break.


Yes, I now start:  cd /var/db/ports; mv * MV/* ; setenv NO_DIALOG=YES
Before:  cd /usr/ports; make BERKLIX_CLIENT=YES # Uses ports/*/Makefile.local
(still innumerable breaks of course on 1200 ports inc deps.)

I can re-enable options for a 2nd pass rebuild for the very
few ports need it (maybe some better way?).


That's what I like about poudriere, one port can fail and builds still
continue until as much is built as possible. I also know that
everything is built before changing anything that is installed.


poudriere's `-f' is nice to accept a list.
But I havent found a way to build my list yet from my Makefile.local eg
cd /usr/ports; make BERKLIX_CLIENT=YES echo_my_category_and_port
I'll probably hack bsd.port.mk & bsd.port.subdir.mk


make all-depends-list
also -
make build-depends-list
make run-depends-list
make package-depends-list
make test-depends-list

To create a list of ports I have installed I just use
pkg info -aqo | sort > myports.list

For setting options, I created /usr/local/etc/poudriere.d/mypkg-make.conf
and filled it with lines like

DEFAULT_VERSIONS=  apache=2.4 perl5=5.20 pgsql=9.5
OPTIONS_SET=   OPTIMIZED_CFLAGS CPU_OPTS SIMD MMX SSE SSE2 SSSE3
x11-servers_xorg-server_SET= DEVD SUID
x11-servers_xorg-server_UNSET= HAL

then I use
poudriere bulk -j 10stableamd64 -p myports -z mypkg -f myports.list
that way these settings are only used when building my pkg repo and not
when I test build any ports (use poudriere.d/make.conf for settings to
be used in all poudriere builds).

My /etc/make.conf only contains -
.include "/usr/local/etc/poudriere.d/mypkg-make.conf"
so the same setting are used for any manual port builds as well as my
poudriere created pkg repo.


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

[Mark Millard]

Julian Elischer julian at freebsd.org wrote on Mon Dec 12 16:15:32 UTC 2016:

> The problem I get hit by is that the quarterly packages are deleted 
> immediately on the creation of the next quarterly set.

Packages: true --but not true of svn's sources for ports: 

https://svnweb.freebsd.org/ports/branches/201*Q*/

svn has 2014 's, 2015 's, and 2016 's sources for each of the
quarters: Q1 , Q2 , Q3 , Q4 .

Things seem to be set up more for source based builds 
(or local package builds and distribution based on
such sources for such builds).

(Not that I'm doing anything where I depend on the
issues or distinctions. I just noted the quarterly
history that is available and where it happens to
exist --which may well be obvious to most folks
involved.)

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

[Kevin Oberman]

On Mon, Dec 12, 2016 at 11:31 AM, Julian H. Stacey  wrote:

> > I would say this rarely happens with the default setup, the more port
> > options you change the more likely it is something will break.
>
> Yes, I now start:  cd /var/db/ports; mv * MV/* ; setenv NO_DIALOG=YES
> Before:  cd /usr/ports; make BERKLIX_CLIENT=YES # Uses
> ports/*/Makefile.local
> (still innumerable breaks of course on 1200 ports inc deps.)
>
> I can re-enable options for a 2nd pass rebuild for the very
> few ports need it (maybe some better way?).
>
> poudriere's `-f' is nice to accept a list.
> But I havent found a way to build my list yet from my Makefile.local eg
> cd /usr/ports; make BERKLIX_CLIENT=YES echo_my_category_and_port
> I'll probably hack bsd.port.mk & bsd.port.subdir.mk
>
> ${CATEGORIES}/${PORTNAME} is not quite usable, as eg mail/exmh2 emits
> "mail tk/exmh". Maybe just `pwd` & strip with sed PORTSDIR ?
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
>  Reply below, Prefix '> '. Plain text, No .doc, base64, HTML,
> quoted-printable.
>  http://berklix.eu/brexit/#stolen_votes


Just to d one more opinion to this thread, I really agree with Julian that
there needs to be a saved quarterly and an active quarterly for exactly the
reasons he stated. the jump from quarter to quarter obviates many of the
advantages of a quarterly branch

Second, I am a bit bewildered at the people who have so much trouble  with
building from ports. I use portmaster and really wish there was an option
to try to continue when a port bombs, but it works well for me. Just this
weekend I had to re-build about 90 ports and it went of without a hitch. It
is to have at least some understanding of how ports work to minimize
problems. Thing like MAKE_JOBS_UNSAFE and trying to wait a bit (a few
hours) and trying to update the sources when something fails. I do wish all
of this was better documented, though. Guess I should try doing something
about that.
--
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 ports collection has some serious issues

[Julian H. Stacey]

> I would say this rarely happens with the default setup, the more port
> options you change the more likely it is something will break.

Yes, I now start:  cd /var/db/ports; mv * MV/* ; setenv NO_DIALOG=YES
Before:  cd /usr/ports; make BERKLIX_CLIENT=YES # Uses ports/*/Makefile.local
(still innumerable breaks of course on 1200 ports inc deps.)

I can re-enable options for a 2nd pass rebuild for the very
few ports need it (maybe some better way?).

poudriere's `-f' is nice to accept a list.
But I havent found a way to build my list yet from my Makefile.local eg
cd /usr/ports; make BERKLIX_CLIENT=YES echo_my_category_and_port
I'll probably hack bsd.port.mk & bsd.port.subdir.mk

${CATEGORIES}/${PORTNAME} is not quite usable, as eg mail/exmh2 emits 
"mail tk/exmh". Maybe just `pwd` & strip with sed PORTSDIR ?

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich
 Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable.
 http://berklix.eu/brexit/#stolen_votes
___
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

[Julian Elischer]

On 8/12/2016 8:28 PM, Baptiste Daroussin wrote:

On Thu, Dec 08, 2016 at 05:16:24AM +, Daniil Berendeev wrote:

Hello guys!

First of all, it's not a hate mail, I appreciate all the work done on
the system and I enjoy using FreeBSD every day.

But after some recent experience I'd like to point out some problems
that make using the ports collection uncomfortable and painful.

Some overview before we start:
* Why I use ports over pkg?
Because, generally, packages are built with poor default options, for
example moc isn't able to play .alac/.mod and that's frustrating.

Lot's of work has been done over the last years improve the default options for
general pupose cases. Have you open an issue about that one?


but we still need a way to specify "minimum options please" to stop 
dependency fanout from going too wild.
I touched a port last week that required about 200 others, a lot of 
which would not have been needed for what I would call a common 
functionality configuration.





Have you considered using things like poudriere that would allow you to build
your own repository with your own set of packages and options.

You will benefit:
- ability to use pkg for your upgrades
- ability to use customize your packages
- safe rebuild process (in case of broken ABI)

Best regards,
Bapt
I'm actually slowly moving to this if I can work out how to specify my 
own chroot image, and a few other things I need to tweak. (my own sets 
of patches to add).



___
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

[Julian Elischer]

On 8/12/2016 6:05 PM, Vlad K. wrote:

On 2016-12-08 06:16, Daniil Berendeev wrote:


I mean, they are the FIRST landing point of a change. And the only 
QA we ask for that change is a confirmation that poudriere and 
portlint have been run, the rest is at liberty of committers how far 
they'll go with own testing before they commit. For many, only 
builds against -CURRENT or latest -RELEASE are done because it's 
very time consuming to test against all supported FreeBSD versions, 
and not just versions but various permutations like different 
pythons etc... When it comes to some defaults like OpenSSL (or any 
kind of dependency on it), all of those tests are required.


The problem is, FreeBSD doesn't have a STABLE repo that would 
receive gradual updates from HEAD as they prove themselves stable. 
QUARTERLY != STABLE, it's just a snapshot of whatever state HEAD is 
in, with a loose promise the ports in it will receive "security and 
bugfixes only" but that's a separate set of issues.


The problem I get hit by is that the quarterly packages are deleted 
immediately on the creation of the next quarterly set.
so by definition, when you've spent 3 months getting the quarterly pkg 
collection reliable and correct, it gets deleted.
I think there should be two quarterly pkg collections available at any 
time:
The one we are stabilising, and the previous stable set (called beta 
and stable or something like that).

the stable one is basically read-only except for security fixes.
As it is when you get the new quarterly packages, they are straight 
off head, because the branch was just made.




There are some solutions and we don't have to NIH or reinvent the 
wheel. Just looking at what other open source projects do with, say, 
GitHub and continuous integration testing, every pull request gets 
an automated test. Why don't we do that? Is it difficult to 
implement it?


I am also convinced that such testing can be automated and a true 
"STABLE" repo can be made instead of manual QUARTERLY that breaks 
promises.
I think this is heading in the right direction..  at the end of the 3 
month stabilisation it goes to stable.



8) ports with vulnerabilities.
They exist in the tree and on build attempt they shout that they won't
build without DISABLE_VULNERABILITIES=yes. The catch is that there is
always a bunch of ports with vulnerabilities. So if you are doing a


That's just a nature of it, and the consequence of VuXML being a 
separate port that gets often updated first, as it's better to 
announce the vuln before it was fixed. And fixing is bound to 
maintainer timeouts, poor issue tracking via Bugzilla, etc...




I hope that my mail will produce a productive discussion that will 
lead

to some good decisions for fixing these problems.


Probably not. I've already posted about issues with head/quarterly, 
hoping for a discussion, never happened. Others have complained 
about the same problem, but no constructive discussion ensued. Is my 
frustration coming through, yet? :)


yeah it's not working well at the moment.  The procedures could do 
with some tuning for sure.










___
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

[scratch65535]

[Default] On Mon, 12 Dec 2016 13:55:57 +0100, Kurt Jaeger
 wrote:

>Hi!
>
>> >> On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
>> >>> I have to admit that I avoid ports if at all possible because
>> >>> I've hardly ever been able to do a build that ran to completion.
>[...]
>> >Note that there are over 26000 ports, over 1600 port maintainers and
>> >hundreds of third party projects get updated every day. While the port
>> >maintainers spend a good portion of their spare time trying to keep it
>> >building there will be times that some ports fail to build.
>> 
>> Which, I think you must agree, is a prima facie case for
>> lengthening the release cycle.  
>
>While I can understand where this comes from, it can be read as
>"slow down the world, it's too fast" 8-}

Well, that part of the world is under our control, and it's
currently not working at all well, so...?


>
>> Perhaps The Major Problem currently is that the makefile goes and
>> fetches code chunks from sources that are out of our control. [...]
>
>> Contrast that with how it would be if the maintainer got one copy
>> of every potential chunk at the beginning of the cycle and stored
>> it in ports so that everyone who builds the port builds against a
>> known-good set of bits.  It would be both more stable and faster.
>> But that's not how it's done.  Why not? 
>
>As far as I know: The idea was to track upstream, not try to become
>upstream. Otherwise the changeset (distfiles) repositories would
>be come much larger to maintain on the FreeBSD side.

I'm sure that's true.  But it's not working, and in fact can't
work except by accident because it's uncontrolled.

Your point about the distfiles repositories is well-made.   How
about storing them centrally, then, but only download them to the
local boxes for the build.  I.e., portsnap would fetch what it
fetches now except for distfiles.  Then if someone does some
build, all the files for the build would be slurped from one of
the portsnap.freebsd.org distfile mirrors. 

And if only the production-quality code were stored
centrally--nothing beta or [shudder] alpha, that would drop the
storage requirements considerably.  I used to be appalled at
seeing something being pulled in that was at v0.03 or something
similarly  horrible.   People who like living dangerously with
pre-alpha code can get their from the originators, just as they
do now.   
  
___
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

[RW via freebsd-ports]

On Sun, 11 Dec 2016 19:42:07 -0700
Janky Jay, III wrote:

> Hello scratch,
> 
> On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
> > I have to admit that I avoid ports if at all possible because
> > I've hardly ever been able to do a build that ran to completion. 
> > There's always some piece of code that's missing and can't be
> > found, or is the wrong version, et lengthy cetera.   I've never
> > done release engineering, but I honestly can't imagine how some
> > of the stuff that makes its way into the ports tree ever got past
> > QA.  It would get someone sacked if it happened in industry.
> > 
> > If the dev schedule would SLOW DOWN and the commitment switched
> > to quality from the current emphasis on frequency, with separate
> > trees for alpha-, beta-, and real release-quality, fully-vetted
> > code, the ports system might become usable again.  
> 
>   This very, VERY rarely happens to me and I use ports *ONLY* in
> production environments.

I have a desktop with a lot of server ports installed on it and find
that the build problems I have are overwhelmingly desktop related. 

Even on the desktop I don't find it to be more than an irritation.
___
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

[Kurt Jaeger]

Hi!

> >> On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
> >>> I have to admit that I avoid ports if at all possible because
> >>> I've hardly ever been able to do a build that ran to completion.
[...]
> >Note that there are over 26000 ports, over 1600 port maintainers and
> >hundreds of third party projects get updated every day. While the port
> >maintainers spend a good portion of their spare time trying to keep it
> >building there will be times that some ports fail to build.
> 
> Which, I think you must agree, is a prima facie case for
> lengthening the release cycle.  

While I can understand where this comes from, it can be read as
"slow down the world, it's too fast" 8-}

> Perhaps The Major Problem currently is that the makefile goes and
> fetches code chunks from sources that are out of our control. [...]

> Contrast that with how it would be if the maintainer got one copy
> of every potential chunk at the beginning of the cycle and stored
> it in ports so that everyone who builds the port builds against a
> known-good set of bits.  It would be both more stable and faster.
> But that's not how it's done.  Why not? 

As far as I know: The idea was to track upstream, not try to become
upstream. Otherwise the changeset (distfiles) repositories would
be come much larger to maintain on the FreeBSD side.

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

Re: The ports collection has some serious issues

[scratch65535]

[Default] On Mon, 12 Dec 2016 17:01:33 +1030, Shane Ambler
 wrote:

>On 12/12/2016 13:12, Janky Jay, III wrote:
>> Hello scratch,
>>
>> On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
>>> I have to admit that I avoid ports if at all possible because
>>> I've hardly ever been able to do a build that ran to completion.
>>> There's always some piece of code that's missing and can't be
>>> found, or is the wrong version, et lengthy cetera.   I've never
>>> done release engineering, but I honestly can't imagine how some
>>> of the stuff that makes its way into the ports tree ever got past
>>> QA.  It would get someone sacked if it happened in industry.
>>>
>>> If the dev schedule would SLOW DOWN and the commitment switched
>>> to quality from the current emphasis on frequency, with separate
>>> trees for alpha-, beta-, and real release-quality, fully-vetted
>>> code, the ports system might become usable again.
>
>Note that there are over 26000 ports, over 1600 port maintainers and
>hundreds of third party projects get updated every day. While the port
>maintainers spend a good portion of their spare time trying to keep it
>building there will be times that some ports fail to build.

Which, I think you must agree, is a prima facie case for
lengthening the release cycle.  

Too few people trying to do too much work in too little time is a
receipe for disaster.  I've seen it in industry, where
engineering gets tasked with impossible schedules to meet some
business plan dreamed up by the suits.  Burnout City.After I
left the corporate world I used to do QA gigs as a consultant for
easy money, and the guys who'd hire me would have a hard time
suppressing their irritation because I'd find lots of bugs for
which they had no time in their schedule to fix.  But if they
slipped the schedule, they'd get a rocket from further up the
food chain, so it was a no-win for them.

>
>The HEAD of the ports svn repo is for the cutting edge development, a
>quarterly branch is created every three months and is only updated to
>receive security and build or runtime fixes during that time.
>
>The quarterly ports has been setup for a couple of years but doesn't
>seem to be documented well, or it just isn't obvious to find. You can
>use svn to checkout a stable branch by specifying a branch name, such as
>ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
>use the quarterly ports by changing the pkg repo URL from
>pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly

That's interesting.  The ones that break on me are the ones I get
from portsnap.  Does portsnap tap quarterly or something else?

>I would say this rarely happens with the default setup, the more port
>options you change the more likely it is something will break.

That's WHY I avoid ports.  Like Grzegorz, I don't necessarily, or
even usually, want the default options.  But  if my only hope is
to build the default version, why not just install the package,
if there is one --- it's what I'd get if I built the port,  and
the package builder has already done all the work I'd have to do.

Perhaps The Major Problem currently is that the makefile goes and
fetches code chunks from sources that are out of our control. And
it's done fresh for *every* individual build, so J. Random Devguy
somewhere can decide on the spur of the moment to change his
chunk of code, or change where he's keeping it, and suddenly the
build breaks because of version skew or FNF.

Contrast that with how it would be if the maintainer got one copy
of every potential chunk at the beginning of the cycle and stored
it in ports so that everyone who builds the port builds against a
known-good set of bits.  It would be both more stable and faster.
But that's not how it's done.  Why not? 
___
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

[Shane Ambler]

On 12/12/2016 13:12, Janky Jay, III wrote:

Hello scratch,

On 12/11/2016 03:35 PM, scratch65...@att.net wrote:

I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion.
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera.   I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA.  It would get someone sacked if it happened in industry.

If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.


Note that there are over 26000 ports, over 1600 port maintainers and
hundreds of third party projects get updated every day. While the port
maintainers spend a good portion of their spare time trying to keep it
building there will be times that some ports fail to build.

The HEAD of the ports svn repo is for the cutting edge development, a
quarterly branch is created every three months and is only updated to
receive security and build or runtime fixes during that time.

The quarterly ports has been setup for a couple of years but doesn't
seem to be documented well, or it just isn't obvious to find. You can
use svn to checkout a stable branch by specifying a branch name, such as
ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
use the quarterly ports by changing the pkg repo URL from
pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly


This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.


I would say this rarely happens with the default setup, the more port
options you change the more likely it is something will break.


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

[Grzegorz Junka]

On 12/12/2016 02:42, Janky Jay, III wrote:

Hello scratch,

On 12/11/2016 03:35 PM, scratch65...@att.net wrote:

I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion.
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera.   I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA.  It would get someone sacked if it happened in industry.

If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.

This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.

Being a port maintainer myself, I depend on people reporting any issues
they run into in order to provide the most robust and dependable port I
can. If people never reported any issues and I had no idea there was an
issue with my port, how would I fix it? So, please, PLEASE report any
issues with ports that aren't building. It's not too time consuming on
your part. Just a simple BUG report and how to re-produce and you're
finished.

Kind Regards,
Janky Jay, III




I second scratch. Building the ports with default options may not be an 
issue but I am rarely (if ever) able to build all 1000+ selected ports 
(using poudriere) with the options that I selected. Whenever I can I am 
raising issues with port maintainer but they very rarely get addressed, 
at least in timely fashion. Even with just 1000+ ports, if an issue 
takes a few weeks to resolve (which would be great) it's highly probably 
that at least one other port gets broken by the time the first issue is 
resolved. With that approach I would never be able to cleanly build all 
the ports that I need. So, to make at least some of the build 
successful, I have to revisit various options and try to disable them to 
verify which ones will allow me to build the ports successfully.


It's not as much a compliant, as I understand it's all done by 
volunteers in their free time, but it makes me wonder how FreeBSD even 
gets its current popularity within the industry with such stability.


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"