FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ editors/vile| 9.8q| 9.8s +-+ editors/xvile | 9.8q| 9.8s +-+ net-mgmt/mk-livestatus | 1.2.8p13| 1.2.8p14 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
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
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
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
Since you insist it's perfect, I thought I'd try synth... On 2016-Dec-16 09:06:30 -0600, John Marinowrote: >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
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 WervenNotice: this e-mail address wil expire on Sat 24 Dec 2016. signature.asc Description: PGP signature
Re: Dropping enigmail support from enigmail
Martin Birgmeierwrites: > After upgrading to thunderbird-45.5.1_6 I noticed that enigmail (and > lightning) support were gone from thunderbird. I tried to find a > replacement package until I read the svn log message: Lightning had 2 copies, only one of those was removed. For Enigmail see /usr/ports/UPDATING from 20161216. > I think a decision to remove such an essential component should not be > taken so lightly, especially when the actual port version (45.5.1) has > not even changed. Why the version should change? Enigmail isn't part of Thunderbird distribution but just one of third-party extensions you can find on addons.mozilla.org. For historic reasons it was bundled with the port but the requirment is gone. ENIGMAIL option was unmaintained beyond updates which were irregular. And it was bound to get in the way if anyone attempted to refactor the current maintenance nightmare gecko@ is in. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Dropping enigmail support from enigmail
After upgrading to thunderbird-45.5.1_6 I noticed that enigmail (and lightning) support were gone from thunderbird. I tried to find a replacement package until I read the svn log message: gecko: drop ENIGMAIL, LIGHTNING to simplify updates ENIGMAIL can still return as www/xpi-enigmail but, alas, xpi-* ports and their framework are mostly unmaintained. So this means that after a simple PORTREVISION change I cannot send, receive, or reread encrypted mails any more. I think a decision to remove such an essential component should not be taken so lightly, especially when the actual port version (45.5.1) has not even changed. What is being planned to remedy this unfortunate situation? -- Martin ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
> On 17 Dec 2016, at 20:47, Alphons van Wervenwrote: > > 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
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
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 WervenNotice: this e-mail address wil expire on Sat 24 Dec 2016. signature.asc Description: PGP signature
Re: The ports collection has some serious issues
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
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
On 12/17/2016 12:34, abi wrote: 2. It doesn't provide dialog for port options, so 2.1 I don't receive information if port options have changed. I don't know what else will be pulled to my system after port tree update. which of course is a false statement. If you set port options which then change, Synth will stop and tell you to reconfigure or remove the saved port options. Not at all. For example, let's assume I go recommended way and have options for ports with not default settings. Let's say, I have perl with default options (no OPTIONS file). Let's say port maintainer adds new option, [NSA Backdoor] Perl will be silently compiled with that option, right? Yes. If you don't explicitly save the options then Synth has no way to detect a change in options. This is not paranoia, here is example from real world - I rebuilded one port and noticed new option - [USE GCC] with default On. I really don't want that gnu beast in my system, so I investigated the problem and suggested patch to compile port under clang. Everyone happy. We can search PR database if you don't believe me. If I was synth user, I've ended with gcc pulled. If your view of the world means that any or all ports maintainers are out to get you, then yes, I see your problem. There are ways to recursively set every possible option though. You can easily write a script to iterate your build list and recursively check every option using the standard ports framework. If you did that, then synth would detect every option change and stop. 2.2 If I make option files for all ports, synth fails to rebuild repository if port and it's options are out of sync. yes, of course. If you give it impossible instructions, it will stop and ask you to fix them. Any reasonable person would want to be informed when the options are incorrect. Did you also notice that extended use of portmaster resulted in dozens of obsolete options files that you weren't aware of? So your criticism here is that you think Synth should just ignore these bad configurations? No, I didn't notece obsolete options. Maybe my /var/db/ports is a complete mess and I should cry in tears. but when portmaster encounters new options it invokes dialog4ports and let me fix the problem. If this leaves some staled OPTIONS file, I'd say it's portmaster bug, not design feature. We all know that portmaster is in rather poor shape. The detection of changed options by ports framework doesn't always work. It definitely doesn't work if portmaster is controlling it. You shouldn't rely on this. First of all, synth ignores /etc/make.conf completely. Yes, we As does poudriere, as it was designed to do. As it should do. definitely need another place to keep global make options, however DEFAULT_VERSIONS suggestion is a bad advice here. Here is example: recently ports framework deprecated perl 5.20 and switched to 5.24 portmaster users should recompile all ports depended on perl (from my point of view this is done not very reliable), but when it comes to new perl, portmaster will invoke dialog4ports. synth user with non-default perl options will receive new perl with default one. I hit this very problem during my synth test when I noticed pgadmin3 liked to postgresql93-client and added DEFAULT_VERSIONS to 96. synth will rebuild everything that changes as a result of change to [profile]-make.conf as does poudriere. It deletes the obsoleted packages first then rebuilds everything that's missing. It works. If you use "synth status" to give it a build list, of course it's also going to keep building the old perl because you told it to. That's just a convenience command. If you want to be exact, you maintain a discrete build list of the prime ports. When in doubt, you can always remove all and reinstall the prime list after the repository is brought up to speed. That's not necessarily done often, but it is guaranteed to always work. I see how synth can be used in pkg framework, I even agree that synth is poudriere done right and I feel I will use synth test feature for ports I maintain, what I fail to see, how I can use it to keep my laptop updated. I'm not asking for pony here, the examples I provided (if true) lead to overcomplexity maintaining packages up to date. I guess it just takes more experience. It's definitely not more complex than portmaster. I would say it's simpler. Plus the fact that portmaster can only build serially while both synth and poudriere build in parallel is a huge advantage to any single system user. John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
graphics/ocropus - new repository?
FWIW, it looks like https://github.com/tmbdev/ocropy is a (new) repository for ocropus source code. HTH -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
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
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
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
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
On 12/17/2016 07:55, Michael Gmelin wrote: On 17 Dec 2016, at 14:26, Alphons van Wervenwrote: 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
On 17/12/2016 13:22, Torfinn Ingolfsen wrote: On Fri, Dec 16, 2016 at 3:45 PM, John Marinowrote: Now, regarding synth: as I have already said, I have no special interest in package builders. I do need a tool to build and install the ports I use, and my current tool (portupgrade or manual building) still works for that. I might try synth in the future sometime, but for tools that I have no special interest in, I prefer that they are a bit more mature. I use my own "metric" to measure maturity of a tool - I read users's feedback in forums and mailinglists, and filter out PEBCACs and other "new user - new tool" issues. Based on that, I will consider using a tool when the discussions around it has quieted down to a reasonable level. All subjective, all by my own standards. If you still find this though to handle and an accusation, my suggestion would be for you to take a long holiday break from computers and spend time with friends and family. Best wishes for the holidays for everyone! I believe the main point is that portupgrade/portmaster shouldn't be used by default by newcomers to FreeBSD. It easily breaks and if you have no knowledge about the system, you will post questions to this list, which seems to be annoying people. I tried to used portupgrade/portmaster in the past and whereas it's fine with small amount of packages, is unusable when there is a few hundred or thousand of them installed. Very often the build was leaving my system messed up because some port only partially build and half of the dependencies were reinstalled and the other half were not. There is no undo in those tools. It's essentially press enter and pray. Grzegorz ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/h2o needs a committer [BZ#213733]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213733 www/h2o update this still needs a committer - I am getting bugged by users waiting for this to land. thanks! A+ Dave ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
> On 17 Dec 2016, at 14:26, Alphons van Wervenwrote: > > 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
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 Wervenmailsig: Help! I'm a prisoner in a Chinese fortune cookie factory. signature.asc Description: PGP signature
Re: The ports collection has some serious issues
On Fri, Dec 16, 2016 at 3:45 PM, John Marinowrote: >> > >> 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
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
I tried to switch from portmaster to synth yesterday. Tests was sponsored by zfs snapshots. I still have strong opinion that synth IS NOT replacement for portmaster and not usable at all. Yes, synth build ports, however it's just builds them. I don't receive information: 1. Why it builds exactly this list of ports, what has changed when I upgraded my ports. 2. It doesn't provide dialog for port options, so 2.1 I don't receive information if port options have changed. I don't know what else will be pulled to my system after port tree update. 2.2 If I make option files for all ports, synth fails to rebuild repository if port and it's options are out of sync. 2.3 When port infrastructure switch to newer default version I must be aware that this change occur and set damn options for new default port. So, synth is just a dumb port building tool. If you need your own port options you are in risk. Developer of synth said that the problem is in my 'portmaster thinking' I should change. And now I see that he tried to deprecate portmaster! Fuck it. Until synth gets interactive mode. Probably I will switch to Linux (yes, I know nobody cares) if the ability to keep custom port options will be lost. The only tool for this now is portmaster. Maybe it's my 'portmaster thinking' but I don't understand how one can use synth if he or she want at least be slightly aware what's going on in his/her system. On 17.12.2016 10:49, Hrant Dadivanyan wrote: On Fri, Dec 16, 2016 at 6:42 AM, Peter Jeremy wrote: On 2016-Dec-15 19:31:22 +0100, list-freebsd-ports at jyborn.se wrote: Interestingly, the most vocal proponent of deleting portmaster and portupgrade is the author/maintainer of synch. It's not interesting at all. Synth was in a large part created because people were irrationally sticking with portmaster and more frighteningly gaining new users. Please don't judge what's rational and what's not, because it's community and when many people, even irrationally from your POV, sticking with portmaster, then it's worth to consider and look for a way to keep it up. The point is that these tools are in great shape and to imply otherwise needs proof. It's portmaster that's not receiving updates. In current shape it works well for many people (and demanded by) in community, so why should it be removed ? You can warn as much as you want against, but you can't decide to remove. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Gettext Issues
On Fri, 16 Dec 2016 17:17:52 -0700 "@lbutlr"wrote: >> On 16 Dec 2016, at 00:22, @lbutlr wrote: >>> 2014-11-30 >>> Affects: users of devel/gettext (close to everyone) >>> Author: t...@freebsd.org >>> Reason: >>> The devel/gettext port has been split up in devel/gettext-runtime, a >>> lightweight package containing runtime libraries, and devel/gettext-tools, >>> a package containing developer tools. The devel/gettext port still exists >>> as a metaport. >>> >>> You must first delete the existing installation of gettext and then >>> reinstall it. This will break sudo, so you *must* do this in a root >>> shell (sudo -i) if you use sudo. >> >> I cannot imagine that gettext hasn't been updated on my system in over >> 2 years, but I seem to be having an issue that appears to be related >> to this based on the errors. >> >> Shared object "libintl.so.8" not found, required by "bash" >> >> For example. >> >> I have logged into the console directly as the root user and tried to >> build gettext via portmaster of via make clean && make install but I >> get errors about missing files. >> >> pkg-static: Unable to access file >> /usr/ports/devel/gettext-runtime/work/stage/usr/local/include/autosprintf.h: >> No such file or directory >> >> >> I've tried to build gettext-runtime first, but to no avail. > > To clarify, if I try to make gettext-runtime it ends with: > > install -m 0644 ABOUT-NLS > '/usr/ports/devel/gettext-runtime/work/stage/usr/local/share/gettext' > > Compressing man pages (compress-man) > ls: > /usr/ports/devel/gettext-runtime/work/stage/usr/local/info/autosprintf.info*: > No such file or directory > > And the error is correct, the file does not exist. Can you email me /usr/ports/devel/gettext-runtime/work/gettext-0.19.8.1/gettext-runtime/config.log ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
On Fri, 16 Dec 2016, at 16:34, Roger Marquis wrote: > If portmaster was part of base I'd agree that it should be deprecated, > however, being a port it can be afforded more leeway. All portmaster > needs IMO is a strong WARNING message to be displayed on installation A) > enumerating some of the potential bugs and B) clarifying that portmaster > is third party software that is neither actively maintained nor > supported (or recommended?) by FreeBSD. > > Roger ^ this ^ The key thing that needs to change for newcomers (as a recent one myself) is to give a clear & simple recommendation in the Handbook.. not in ports or whatever after you've sifted the internet looking for more information - the implications of choosing pkg quarterly vs pkg latest, vs poudriere, portmaster etc is not at all clear - it's hard to know what is project supported vs community supported - knowing that e.g. DFLY uses synth exclusively now, and the the FreeBSD build cluster uses poudriere, gives a warm fuzzy feeling Some illustrative use cases are: - sysadmin for servers - personal user who needs custom options I was lucky to run into the first poudriere episode from bsdnow.tv and went with that from the get-go. synth's documentation is superb and keeps getting better. Both are excellent tools. A+ Dave ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ net-mgmt/mk-livestatus | 1.2.8p13| 1.2.8p15 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The ports collection has some serious issues
>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"