Re: Removing documentation
On 02/11/16 14:15, Royce Williams wrote: On Thu, Feb 11, 2016 at 10:33 AM, John Marino wrote: On 2/11/2016 8:25 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? Let me guess. You've spent actually 0.0 nanoseconds preparing on the subject before providing this enlightened take for the list. Having read the entire thread, separate from the relative merits of Synth, the core of Lev's incredulity isn't that off the mark. On the face of it, Synth requiring ncurses seems reasonable ... but its Ada dependency is a bit of a mild POLA violation. Don't get me wrong -- I actually think Ada is pretty cool, and Lev could have been nicer about it ;), but he's essentially right. People's instincts are that software management is core functionality, and should have few unusual dependencies. My earlier side-thread point stands. FreeBSD software management is fragmented. Until that is resolved, a lot of time and effort will be wasted treating the symptoms. Royce Preach it *LOUD*, brother :-) (fragmented package management) For my , that is about *all* RH & Debian have going for them, but yum/RPM et al cover up a multitude of other sins -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ 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: Please commit PR # 206935
Hi! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206935 Done. -- 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: Removing documentation
On Thu, Feb 11, 2016 at 3:41 PM, John Marino wrote: > > On 2/12/2016 1:22 AM, Royce Williams wrote: > > Is the abstraction is happening at the equivalent level here? The > > platforms that I'm thinking of -- that appear to have already solved > > this entire class of problem long ago -- feature wrappers around > > apt-get, not wrappers around dpkg. > > I'm not a linux guy so those things don't mean much the me. The > abstraction layer here is at the appropriate level. I'm not seeing this > fragmentation problem you're talking about, at least not with the newer > tools. It's the long tail of non-newer tools that appears to be a big part of the problem. I think that you and I are in agreement there. But I also think that the older tools do some things well that enough people will miss that it will undermine adoption of newer tools for a while. > > > I'm advocating that we stop quasi-providing four different flavors of > > apt-get. Until there is a single and official mechanism for both > > dependency resolution and configuration option management, the > > fragmentation remains. > > Why do you think this is the case? Ports defines the dependencies and > pkg respects them. I'm not seeing where there more than one method > here. What other ones are there? The current ports/pkg relationship is still fragile, perhaps because it's new. I almost abandoned FreeBSD entirely a couple of months ago when an interesting corner case of the use of pkg managed to unilaterally and without warning delete in its entirety the contents of /usr/local/etc/rc.d in of my jails. Contrast this with the Ubuntu world, where there is a well-baked "unattended-upgrades" option that automatically downloads and upgrades all security updates for both the OS and all third-party packages. > > > If there were no ports system, and everything was package-driven, I'd > > agree. Synth and its cousins exist because people work from ports -- > > which means that dependencies matter. > > Synth exist because people are insisting to build from source (even > irrationally) so they might as well do it correctly. The statement > above doesn't have anything to do with Synth being a binary. If you believe that people who want to build from source are irrational, to me this means that you do not yet understand the current use cases of the software you're purporting to replace. > > If a shell script was so good, why is portmaster unmaintainable? I wasn't advocating for using a shell script. I'm advocating for a core-driven, Foundation-funded initiative to identify requirements and functionality for true, integrated ports and packages management, drive it to completion for parity with modern package management practices, and bring it into core. > > > The laissez-faire "there's no requirement to build from ports" that > > permeates FreeBSD is exactly what's wrong. The fact that half of the > > documentation and quasi-official tools tell people "hey, use one of > > these three ports management tools, or maybe packages, pick what works > > for you -- oh, and be sure to check /usr/ports/UPDATING every time you > > touch any port or package" is a deep symptom of this fragmentation. > > THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT > ITSELF IS BUILT FROM PORTS. You responded to something different. Breathe. :) I'm not saying it's required. I'm saying that it's what many people do -- and probably for reasons that should be identified and understood before dismissing them. > > Because FreeBSD software management itself is not purely package based. > > > > As long as the ports system exists (and I think it should!), the > > management of compilation requirements -- especially for something > > that might need to be bootstrapped early, like a software management > > tool -- is a valid topic. > > Well, except *this* tool will never be in a "bootstrap" path. Above is > completely irrelevant. Besides, if the base is built, ports work, > period. There are no "compilation" requirements. > > > > To be clear: except for the Ada/ruby/whatever dependency chain, my > > beef isn't with Synth qua Synth. It's that every time we spin up Yet > > Another Optional Software Management Tool, we fragment further. If > > Synth becomes the holy grail of package management -- so compelling > > that it becomes the only choice people would want to make, which is > > what I think we need -- then it should become part of base. > > 1) you should focus on retiring the old tools No disagreement there. > > 2) It will never be part of base That's where we differ. I think that a software management suite that has fully identified the use cases would necessarily need to be part of base. And the fact that it's not part of base is only going to make the fragmentation worse over time. Mine is just one opinion, of course. > > 3) no ports tool has even been part of base I know. I think that's bad. > > 4) the "winner" will be determined by me
Please commit PR # 206935
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206935 ___ 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: Removing documentation
On 2/12/2016 1:22 AM, Royce Williams wrote: > Is the abstraction is happening at the equivalent level here? The > platforms that I'm thinking of -- that appear to have already solved > this entire class of problem long ago -- feature wrappers around > apt-get, not wrappers around dpkg. I'm not a linux guy so those things don't mean much the me. The abstraction layer here is at the appropriate level. I'm not seeing this fragmentation problem you're talking about, at least not with the newer tools. > I'm advocating that we stop quasi-providing four different flavors of > apt-get. Until there is a single and official mechanism for both > dependency resolution and configuration option management, the > fragmentation remains. Why do you think this is the case? Ports defines the dependencies and pkg respects them. I'm not seeing where there more than one method here. What other ones are there? > If there were no ports system, and everything was package-driven, I'd > agree. Synth and its cousins exist because people work from ports -- > which means that dependencies matter. Synth exist because people are insisting to build from source (even irrationally) so they might as well do it correctly. The statement above doesn't have anything to do with Synth being a binary. If a shell script was so good, why is portmaster unmaintainable? > The laissez-faire "there's no requirement to build from ports" that > permeates FreeBSD is exactly what's wrong. The fact that half of the > documentation and quasi-official tools tell people "hey, use one of > these three ports management tools, or maybe packages, pick what works > for you -- oh, and be sure to check /usr/ports/UPDATING every time you > touch any port or package" is a deep symptom of this fragmentation. THERE'S NO REQUIREMENT THAT SOMETHING THAT BUILDS PORTS NEEDS THAT ITSELF IS BUILT FROM PORTS. You responded to something different. > Because FreeBSD software management itself is not purely package based. > > As long as the ports system exists (and I think it should!), the > management of compilation requirements -- especially for something > that might need to be bootstrapped early, like a software management > tool -- is a valid topic. Well, except *this* tool will never be in a "bootstrap" path. Above is completely irrelevant. Besides, if the base is built, ports work, period. There are no "compilation" requirements. > To be clear: except for the Ada/ruby/whatever dependency chain, my > beef isn't with Synth qua Synth. It's that every time we spin up Yet > Another Optional Software Management Tool, we fragment further. If > Synth becomes the holy grail of package management -- so compelling > that it becomes the only choice people would want to make, which is > what I think we need -- then it should become part of base. 1) you should focus on retiring the old tools 2) It will never be part of base 3) no ports tool has even been part of base 4) the "winner" will be determined by merit. If some people insist on using inferior/broken/obsolete/unmaintained tools it's their choice and problem. The majority will migrate naturally. This started because I think that if a tool is documented in handbook, it must be maintained (not part of base). I've got no issue with non-base software documented. I was saying that being in the handbook should have a required level of quality and abandoning it would cause the quality to fall under that level. John ___ 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: Removing documentation
On Thu, Feb 11, 2016 at 11:17 AM, John Marino wrote: > On 2/11/2016 9:08 PM, Royce Williams wrote: >> On Thu, Feb 11, 2016 at 10:33 AM, John Marino wrote: >>> >>> On 2/11/2016 8:25 PM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.02.2016 17:28, John Marino wrote: > ports-mgmt/synth. I would love to hear what signficant thing > portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? >>> >>> Let me guess. You've spent actually 0.0 nanoseconds preparing on the >>> subject before providing this enlightened take for the list. >> >> >> Having read the entire thread, separate from the relative merits of >> Synth, the core of Lev's incredulity isn't that off the mark. >> >> On the face of it, Synth requiring ncurses seems reasonable ... but >> its Ada dependency is a bit of a mild POLA violation. >> >> Don't get me wrong -- I actually think Ada is pretty cool, and Lev >> could have been nicer about it ;), but he's essentially right. >> >> People's instincts are that software management is core functionality, >> and should have few unusual dependencies. >> >> My earlier side-thread point stands. FreeBSD software management is >> fragmented. Until that is resolved, a lot of time and effort will be >> wasted treating the symptoms. > > Actually, you missed the fact that synth (nor poudriere) doesnt > re-invent anything. Both are tightly integrated with pkg(8). You spoke > of both as if they were similar to portupgrade. > > The "wrapper situation" that you proposed is already here. So the whole > "fragmented" thing is not really true. Is the abstraction is happening at the equivalent level here? The platforms that I'm thinking of -- that appear to have already solved this entire class of problem long ago -- feature wrappers around apt-get, not wrappers around dpkg. I'm advocating that we stop quasi-providing four different flavors of apt-get. Until there is a single and official mechanism for both dependency resolution and configuration option management, the fragmentation remains. > Synth is a binary. There's no POLA there. If there were no ports system, and everything was package-driven, I'd agree. Synth and its cousins exist because people work from ports -- which means that dependencies matter. > There's no requirement to build from ports, that's an unsubstanciated > invention. Notice that not a single person could defend that position > after a challenge. There's no technical basis for it; it's just emotional. The laissez-faire "there's no requirement to build from ports" that permeates FreeBSD is exactly what's wrong. The fact that half of the documentation and quasi-official tools tell people "hey, use one of these three ports management tools, or maybe packages, pick what works for you -- oh, and be sure to check /usr/ports/UPDATING every time you touch any port or package" is a deep symptom of this fragmentation. > In a straight fly-off against any of the tools, Synth wins hands down > with any objective measurement. Poudriere is slightly more bulletproof > and more appropriate for a cluster (as it was targetted at) but for > average user Synth is better suited. > > It's a concurrent builder. Ada is a concurrent language. How is its > suitability even a debate? Because FreeBSD software management itself is not purely package based. As long as the ports system exists (and I think it should!), the management of compilation requirements -- especially for something that might need to be bootstrapped early, like a software management tool -- is a valid topic. To be clear: except for the Ada/ruby/whatever dependency chain, my beef isn't with Synth qua Synth. It's that every time we spin up Yet Another Optional Software Management Tool, we fragment further. If Synth becomes the holy grail of package management -- so compelling that it becomes the only choice people would want to make, which is what I think we need -- then it should become part of base. If that happened, would we want to ship with Ada in base? If not, why not? Royce ___ 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: Removing documentation
On 2/11/2016 10:32 PM, Matt Smith wrote: > Remember that before portmaster we had cvsup which was written in > Modula-3 and portupgrade which is written in Ruby. Whilst it is nice > that portmaster is just a simple shell script with no dependancies > that's a relatively new thing. I'm familiar with the M3 situation (I actual maintain the M3 port which came in after CVS was removed) and I understand why people are gunshy about obscure languages. I don't think this is a comparable situation though. A broken Synth cannot leave the system in a bad or unrecoverable state. One could remove it and it's products in a second and the machines that used it would continue as normal. There are alternatives (ports, official packages, poudriere, portmaster, etc) so there's no critical path. I'm always aware (and was bitten by) portupgrade and ruby. I know why people wouldn't want that again. Still the situation cannot be compared to Synth. Portmaster was good in that it didn't have its own database and used the ports framework. Poudriere also does that and now Synth, so it's no longer unique in that aspect. Dependencies matter if it's part of a bootstrap process or maybe part of base or in a critical path, but I don't think any of that applies in this case. John ___ 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: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On Feb 11 22:25, Lev Serebryakov wrote: On 07.02.2016 17:28, John Marino wrote: ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? -- // Lev Serebryakov Remember that before portmaster we had cvsup which was written in Modula-3 and portupgrade which is written in Ruby. Whilst it is nice that portmaster is just a simple shell script with no dependancies that's a relatively new thing. -- Matt ___ 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: Removing documentation
On 2/11/2016 9:08 PM, Royce Williams wrote: > On Thu, Feb 11, 2016 at 10:33 AM, John Marino wrote: >> >> On 2/11/2016 8:25 PM, Lev Serebryakov wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> On 07.02.2016 17:28, John Marino wrote: >>> ports-mgmt/synth. I would love to hear what signficant thing portmaster can do that Synth can't. (honestly) >>> Be installed FROM PORTS without all this build-one-more-gcc stuff. >>> Ada? For *port*management* tool? Are you joking? >> >> Let me guess. You've spent actually 0.0 nanoseconds preparing on the >> subject before providing this enlightened take for the list. > > > Having read the entire thread, separate from the relative merits of > Synth, the core of Lev's incredulity isn't that off the mark. > > On the face of it, Synth requiring ncurses seems reasonable ... but > its Ada dependency is a bit of a mild POLA violation. > > Don't get me wrong -- I actually think Ada is pretty cool, and Lev > could have been nicer about it ;), but he's essentially right. > > People's instincts are that software management is core functionality, > and should have few unusual dependencies. > > My earlier side-thread point stands. FreeBSD software management is > fragmented. Until that is resolved, a lot of time and effort will be > wasted treating the symptoms. Actually, you missed the fact that synth (nor poudriere) doesnt re-invent anything. Both are tightly integrated with pkg(8). You spoke of both as if they were similar to portupgrade. The "wrapper situation" that you proposed is already here. So the whole "fragmented" thing is not really true. Synth is a binary. There's no POLA there. There's no requirement to build from ports, that's an unsubstanciated invention. Notice that not a single person could defend that position after a challenge. There's no technical basis for it; it's just emotional. In a straight fly-off against any of the tools, Synth wins hands down with any objective measurement. Poudriere is slightly more bulletproof and more appropriate for a cluster (as it was targetted at) but for average user Synth is better suited. It's a concurrent builder. Ada is a concurrent language. How is its suitability even a debate? John ___ 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: Removing documentation
On Thu, Feb 11, 2016 at 10:33 AM, John Marino wrote: > > On 2/11/2016 8:25 PM, Lev Serebryakov wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On 07.02.2016 17:28, John Marino wrote: > > > >> ports-mgmt/synth. I would love to hear what signficant thing > >> portmaster can do that Synth can't. (honestly) > > Be installed FROM PORTS without all this build-one-more-gcc stuff. > > Ada? For *port*management* tool? Are you joking? > > Let me guess. You've spent actually 0.0 nanoseconds preparing on the > subject before providing this enlightened take for the list. Having read the entire thread, separate from the relative merits of Synth, the core of Lev's incredulity isn't that off the mark. On the face of it, Synth requiring ncurses seems reasonable ... but its Ada dependency is a bit of a mild POLA violation. Don't get me wrong -- I actually think Ada is pretty cool, and Lev could have been nicer about it ;), but he's essentially right. People's instincts are that software management is core functionality, and should have few unusual dependencies. My earlier side-thread point stands. FreeBSD software management is fragmented. Until that is resolved, a lot of time and effort will be wasted treating the symptoms. Royce ___ 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: Can someone take a look at these PRs?
Hi! > can someone take a look at the update to IntelliJ IDEA at > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206489 (besides > updating IDEA to the latest version it also enables new features)? Done. > The new port at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204095 > for some printer PPDs is in the bug tracker since October 2015. Can > someone commit it? Done. You use cups and understand it ? Are you volunteering to fix the outstanding cups PRs 8-) ? https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=cups > Also it would be great if someone could commit the default options > change to sqlite3 at > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206944 (has a patch by > the maintainer). Done. -- 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: Removing documentation
On 2/11/2016 8:25 PM, Lev Serebryakov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 07.02.2016 17:28, John Marino wrote: > >> ports-mgmt/synth. I would love to hear what signficant thing >> portmaster can do that Synth can't. (honestly) > Be installed FROM PORTS without all this build-one-more-gcc stuff. > Ada? For *port*management* tool? Are you joking? Let me guess. You've spent actually 0.0 nanoseconds preparing on the subject before providing this enlightened take for the list. ___ 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: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07.02.2016 17:28, John Marino wrote: > ports-mgmt/synth. I would love to hear what signficant thing > portmaster can do that Synth can't. (honestly) Be installed FROM PORTS without all this build-one-more-gcc stuff. Ada? For *port*management* tool? Are you joking? - -- // Lev Serebryakov -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJWvOAdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePG38P/2y6BiUF0XgBmPPq0KE+Vfui fFeszBcYZ9AfPD92jKXMbvMsMoY93WZRQB69TmQ4c7zXZLQvSvoT9CSjMMzdzOfq UHVuiEpsCz2q4knwij5G9W5IGomxgT9tc/g26tameuZVu8ududFLNCcofX8zS6pb pFLoUTKkALmAJOwyxtMOwtrSGeZXrbq1C6FpXFOXuO7aMcmLA5qDicqdZSNhBDWG 27jjECGM0RyPMChA6OMjYqvzyP6Y3TjAfnxy9PI8S8jXY/oXKVebdRpl27VqRaYw A5gelEb45BGaxF77b35ZTd8gObesoW9i30KmoEEmDTyAwaRjfce8g7WRmvJpNQEy BcYaJYDDtT/oSbLh/XqMNPCmRbNlSaQId4QJmlzpPlbwVHlBtw3EKZS6PVRQG30U Nn40YEiLqhy6uL33VENmsQlRJxnlhOICP24mQUfiWoIYjww91QEL3CCIQilL79rN FarIAv+SVNld+2AnT+Q1WnqrYX5DNSyhIbjm7VpB1GGBnSGXCjeHvkYGl4JAl9H+ 4xm3otpZLU6SsdePSgqJ8fSd0iKygHNixrzYYv+o6DuDEC2JU//G7994r5xM3KXO +CTXd/KlruyK4eIJ32gTcU+nQ21hzlMfgviTLgEKOJplfVWDZ92aFpJaXOnKj4OP LuFstIC8L6cEjxh8Fm5m =JBt1 -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: don't fork portmaster source
On 2/10/2016 5:33 AM, John Marino wrote: >> I'm asking myself how to manage the code. Should i create a new GitHub >> repository? Fork the existing from freebsd/portmaster? How to handle the >> LOCAL Master-Site? > > > Talk to Bryan Drewery. > > "If someone else would like to maintain this please discuss with me and > I will get you access to the github account where the code lives." from > portmaster commit history. > Well, I prefer to mentor someone into the position and see a good track record before giving them full access. Portmaster is depended on by a lot of people and needs special care. I've since told 2 people that once they start sending me good patches/PR I'll grant them access. Said another way I am offering to review patches and be involved with the transition. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: PHP7 package?
Hi! > That's fewer than I'd have thought, but there are also ports like > php56-redis which don't show up as "pecl" though they are in the PECL > repo. Then we have to add them manually to the 'ports-to-test' list. > I'd say that in order to be rigorous, all php*- and pecl- ports need to > be tested (at least) for compilation against php70 in in a clean system, > and it's a good opportunity to update all with current versions. I'm > happy to help. Feel free to contact me off list. Three tests then: build-test, run-test, use-test -- 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: PHP7 package?
Hi, I am aware of the problems with pecl and some pear ports. Still thinking what the best solution is, one of the problem is that pecl updates with php7 support are not backwards compatible, which means that we have to do something like pecl-name-php7 or so. Not sure yet. Also I've updated php7 to the latest version, there are still 2 problems to settle, one is https://github.com/miwi-fbsd/miwi-ports/issues/8, second is that there still some problems with MySQL leftovers. I will try to sort them out over the coming weekend. - Martin On Thu, Feb 11, 2016 at 11:36 PM, Jim Ohlstein wrote: > Hello, > > On 2/11/16 10:12 AM, Kurt Jaeger wrote: > >> Hi! >> >> In fact, I'd guess there are hundreds of PECL modules >>> in the ports tree that either have not been updated to PHP 7.0 upstream >>> or have not been updated in the ports tree if they have been updated >>> upstream. >>> >> >> List of PECL modules: >> >> portfind pecl | wc -l >> 137 >> >> Maybe put the list in the wiki, and start some upgrade orgy ? >> >> Sounds 'somewhat' doable. >> >> > That's fewer than I'd have thought, but there are also ports like > php56-redis which don't show up as "pecl" though they are in the PECL repo. > The current port uses a GH source. See https://pecl.php.net/package/redis > and > https://svnweb.freebsd.org/ports/head/databases/php56-redis/Makefile?revision=403460&view=markup > for an example. In fact, that GH source is also outdated and results in a > redirect. > > root@rubicon:~ # curl -I https://github.com/nicolasff/phpredis > HTTP/1.1 301 Moved Permanently > Server: GitHub.com > Date: Thu, 11 Feb 2016 15:28:34 GMT > Content-Type: text/html; charset=utf-8 > Status: 301 Moved Permanently > Cache-Control: no-cache > Vary: X-PJAX > Location: https://github.com/phpredis/phpredis > > I'd say that in order to be rigorous, all php*- and pecl- ports need to be > tested (at least) for compilation against php70 in in a clean system, and > it's a good opportunity to update all with current versions. I'm happy to > help. Feel free to contact me off list. > > > -- > Jim Ohlstein > > > "Never argue with a fool, onlookers may not be able to tell the > difference." - Mark Twain > ___ 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: PHP7 package?
Hello, On 2/11/16 10:12 AM, Kurt Jaeger wrote: Hi! In fact, I'd guess there are hundreds of PECL modules in the ports tree that either have not been updated to PHP 7.0 upstream or have not been updated in the ports tree if they have been updated upstream. List of PECL modules: portfind pecl | wc -l 137 Maybe put the list in the wiki, and start some upgrade orgy ? Sounds 'somewhat' doable. That's fewer than I'd have thought, but there are also ports like php56-redis which don't show up as "pecl" though they are in the PECL repo. The current port uses a GH source. See https://pecl.php.net/package/redis and https://svnweb.freebsd.org/ports/head/databases/php56-redis/Makefile?revision=403460&view=markup for an example. In fact, that GH source is also outdated and results in a redirect. root@rubicon:~ # curl -I https://github.com/nicolasff/phpredis HTTP/1.1 301 Moved Permanently Server: GitHub.com Date: Thu, 11 Feb 2016 15:28:34 GMT Content-Type: text/html; charset=utf-8 Status: 301 Moved Permanently Cache-Control: no-cache Vary: X-PJAX Location: https://github.com/phpredis/phpredis I'd say that in order to be rigorous, all php*- and pecl- ports need to be tested (at least) for compilation against php70 in in a clean system, and it's a good opportunity to update all with current versions. I'm happy to help. Feel free to contact me off list. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain ___ 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: PHP7 package?
Hi! > In fact, I'd guess there are hundreds of PECL modules > in the ports tree that either have not been updated to PHP 7.0 upstream > or have not been updated in the ports tree if they have been updated > upstream. List of PECL modules: portfind pecl | wc -l 137 Maybe put the list in the wiki, and start some upgrade orgy ? Sounds 'somewhat' doable. -- 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: PHP7 package?
Hello, On 2/7/16 8:32 AM, Kurt Jaeger wrote: Hi! This post suggests that a php7 port should be coming soon https://docs.freebsd.org/cgi/getmsg.cgi?fetch=86492+0+archive/2016/freebsd-ports/20160117.freebsd-ports but there is stil no port or package available for php7 You can check out the repo and build them yourself, it works, see it at https://a1.opsec.eu/test.php I cloned the ports, created a (separate) poudriere ports collection and added them to that. No problem building the php70 port or most of the modules that I use in php70-extensions. The pdflib module is a PECL module that hasn't been updated to PHP 7.0 and chokes. So do some other PECL extensions. In fact, I'd guess there are hundreds of PECL modules in the ports tree that either have not been updated to PHP 7.0 upstream or have not been updated in the ports tree if they have been updated upstream. I found examples of both (pecl-APCu has been updated upstream but not in ports, pecl-memcache has not been updated upstream) in modules I use regularly. Some modules are hosted on Github and are branched for PHP 7.x but are not at the "release" stage and have to be edited with a Github "tag" (phpXx-redis being a case in point - it builds against php70 if it is modified to use GH tag "0d4b421", and a similar situation with pecl-igbinary which has to be completely reworked as the update is not available in PECL, only on GH). Of course I haven't tested most of them in any meaningful way so the fact that they compile does not indicate that I believe they work as intended. This may in fact be a larger sticking point in adoption of PHP 7.x than backward code incompatibility, though that's a subject for another day on another mailing list. Thank you miwi@ et al for the work. Clearly much remains to be done. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain ___ 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"
Can someone take a look at these PRs?
Hi, can someone take a look at the update to IntelliJ IDEA at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206489 (besides updating IDEA to the latest version it also enables new features)? The new port at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204095 for some printer PPDs is in the bug tracker since October 2015. Can someone commit it? Also it would be great if someone could commit the default options change to sqlite3 at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206944 (has a patch by the maintainer). 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: synth documentation
On 10.02.2016 18:29, kpn...@pobox.com wrote: On Wed, Feb 10, 2016 at 10:11:25AM +0100, John Marino wrote: On 2/10/2016 10:01 AM, Kurt Jaeger wrote: So I guess [A] could say FreeBSD package builder is compromised (intentionally by FreeBSD project or unknown to all due a hacker). And I guess that could be possible, but the counter is: If you cant' trust packages built by FreeBSD, how can you trust the FreeBSD base not to have a trojan? Which would mean that only the people that *also* build FreeBSD from source would have a leg to stand on. So I will concede that case: If you accept no binaries at all from FreeBSD and only build base and packages from source, then you have a point. But still the response, "Then don't complain" applies. It's a conscious decision and consequences of decisions must be accepted. Well, no, actually there's no end of it. Can you trust the compiler used to compile FreeBSD from source? Can you trust your motherboard's firmware to not install patches onto FreeBSD after compiling from source? (This is old hat on Windows to make it easy for people to get the right drivers from a fresh install of Windows.) Can you trust the update procedure for your board's firmware? Can you trust that there isn't a trojan in your CPU's microcode? Seriously, it never ends. You just have to pick a level and say you trust everything below that. Not "everything below". It is much easier to trust specific parts instead of everything below a specific part. You can say i trust the assembler part of FreeBSD but not driver X even if both are in the core. The source of FreeBSD is big and many people are involved. Even when trying to get the same high quality for everything this is not possible. Not only by the involved person and their various level of trustfulness - which does not mean they are suspicious. Many bad thinks happens just because of missing knowledge and not because of criminal attempts. It is also because of the chosen tools including the language. Many very low level constructs are not completely testable just because of the used language. Oh - and then there are these languages where many parts are undefined, so it is not possible to write a program in a way which is always correct. The last point is a big advantage of Ada, which is one of the rare languages which is nearly completely defined and which compiler is tested by "trusted institutions". Of course you can distrust them, but in reality you really feel the difference. Also distrusting in this level is more a philosophical problem. Why should i end which the microcode in my CPU? I should distrust every doctor, food, institution and person on earth. I should even distrust this paper from this unknown guy, which could be just a very good disinformation technique. There are multiple ones in this manner. There is no guarantee for trust. Maybe i should distrust myself and my existence - there are many stories where a human becomes aware that it is just a simulation. Or lives in a very big TV-show without knowing. You could not know. But this is wrong. Trust is not something a different person/tool/institution/etc offers to me or gained by somebody or something. Trust is something i am able to. Of course it would be silly to trust everything and everyone. But so is distrusting. You need to learn to handle the case of somebody or something misuse your trust. And how to raise the barrier for a misusage. This can be learned from persons who knows this - and they provide far better quality in various parts of our live; for example in source-code ;) 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: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
On Wed, Feb 10, 2016 at 07:57:55PM -0500, Daniel Eischen wrote:
> On Wed, 10 Feb 2016, Baptiste Daroussin wrote:
>
> > On Wed, Feb 10, 2016 at 10:16:44PM +0100, Dimitry Andric wrote:
> >> On 10 Feb 2016, at 20:10, Daniel Eischen wrote:
> >>>
> >>> I'm trying to upgrade my ports with a set that I built using poudriere.
> >>> I'm running FreeBSD-current r295354, pkg 1.6.3.
> >>>
> >>> The packages are here on my local (localhost, vega) box:
> >>>
> >>> /usr/local/poudriere/data/packages/11amd64-default
> >>>
> >>> My repo pkg.conf (vega.conf) looks like this:
> >>>
> >>> vega: {
> >>>url:
> >>> "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
> >>
> >> Try using file:/// (e.g three slashes). Yes, this is ugly, and Tim
> >> Berners-Lee has even apologized for it... :-) [1]
> >>
> >> -Dimitry
> >>
> >> [1] http://news.bbc.co.uk/2/hi/technology/8306631.stm
> >>
> > Yes that is it.
> >
> > Note that I will relax it in pkg 1.6.4 to be released very soon, I have
> > been too
> > strict by accident in pkg 1.6.3 (I have never thought anyone would use
> > file://
> > or file:/.
> >
> > pkg respects RFC2396 but there are not reason not to relax it a bit given
> > some
> > users seems to use the previous syntax
>
> No worries, now that I have the correct syntax. Thanks!
FYI pkg 1.6.4 is out and relaxes the syntax
Best regards,
Bapt
signature.asc
Description: PGP signature
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/weathermap | 1.1.1 | 16.0.0 +-+ 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"
