Re: The future of portmaster
On Feb 22, 2017 11:36 AM, "rollingbits (Luc wrote: On Feb 19, 2017 12:13 PM, "Matthias Andree" wrote: Am 17.02.2017 um 08:37 schrieb abi: > From my point of view, jails are overkill. Chroot should be enough and > it would be nice if portmaster starts building in clean environment. Please use poudriere or some other tool instead, there are some that were designed for clean-room rebuilds, which portmaster was *not* designed to do, and should not be turned into. Just out of curiosity, as bad software build interactions shows itself only in dirty environments, what is the tool that will catch this kind of bug when portmaster have gone away? Lc -- rollingbits -- 📧 rollingb...@gmail.com 📧 rollingb...@terra.com.br 📧 rollingb...@yahoo.com 📧 rollingb...@globo.com ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
On Feb 22, 2017 11:36 AM, "rollingbits (Lucas)" wrote: On Feb 19, 2017 12:13 PM, "Matthias Andree" wrote: Am 17.02.2017 um 08:37 schrieb abi: > From my point of view, jails are overkill. Chroot should be enough and > it would be nice if portmaster starts building in clean environment. Please use poudriere or some other tool instead, there are some that were designed for clean-room rebuilds, which portmaster was *not* designed to do, and should not be turned into. Just out of curiosity, as bad software build interactions shows itself only in dirty environments, what is the tool that will catch this kind of bug when portmaster have gone away? Sorry for the double post. I'm not trying to answer myself but then are you peoples proposing fix the ports in a way that a "make upgrade" will do the right thing now that there is a better package system and this will let us drop solutions as postmaster? Lc ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
>when portmaster have gone away? What? WHAT? portmaster going away??? I hope not Anton ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
> On 30 May, 2017, at 7:51, Anton Shterenlikht wrote: > >> when portmaster have gone away? > > What? WHAT? > > portmaster going away??? > > I hope not > > Anton The ports tree continues to evolve. Major new features are planned and in the process of being implemented. These changes will break all the port-building tools. poudriere and synth are actively developed, so they will quickly support the new changes. portmaster and portupgrade are no longer being actively developed, so it is anticipated that they will stop working until somebody fixes them (if at all). So no, portmaster isn't going away. But, there's no guarantee that it will keep working. We strongly, strongly advise everyone to use poudriere or synth to build their ports, and then plain old "pkg upgrade" to handle updates. The vast majority of problems reported on this mailing list exist only in portmaster/portupgrade, because they do not do clean builds. At this point, portmaster should only be used by people with enough ports development experience to understand and mitigate conflicts and various build errors. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
>From ad...@adamw.org Tue May 30 15:03:31 2017 > >The ports tree continues to evolve. Major new features are planned and in the >process of being implemented. These changes will break all the port-building >tools. oy vei >poudriere and synth are actively developed, so they will quickly support the >new changes. portmaster and portupgrade are no longer being actively >developed, so it is anticipated that they will stop working until somebody >fixes them (if at all). I last used poudriere a couple years back. It is much more involved than portmaster (obviously, these 2 tools are not doing the same job) >So no, portmaster isn't going away. But, there's no guarantee that it will >keep working. We strongly, strongly advise everyone to use poudriere or synth >to build their ports, and then plain old "pkg upgrade" to handle updates. because my experience of poudriere was mixed, I haven't used it at all on amd64. pkg is great. And when occasionally I need non-default options I use portmaster. > >The vast majority of problems reported on this mailing list exist only in >portmaster/portupgrade, because they do not do clean builds. At this point, >portmaster should only be used by people with enough ports development >experience to understand and mitigate conflicts and various build errors. I agree that a dirty environement is mostly the source of bad portmaster builds. However, to create the whole poudriere enviroment to build a port a week, or maybe a month, seems like an overkill. Yes, I know, it's a volunteer project, things evolve, unless somebody steps in... If my recollection of poudriere is correct, I'll need a separate ports tree? And if I only need to build a single port with custom settings, I'll have to start every time from scratch? And if I want to use this single port with default settings with my other ports, I need to make sure the 2 port trees are in sync. Sorry if I don't do poudeire justice, it's been a while... Anton ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
> On 30 May, 2017, at 8:15, Anton Shterenlikht wrote: > >> From ad...@adamw.org Tue May 30 15:03:31 2017 >> >> The ports tree continues to evolve. Major new features are planned and in >> the process of being implemented. These changes will break all the >> port-building tools. > > oy vei > >> poudriere and synth are actively developed, so they will quickly support the >> new changes. portmaster and portupgrade are no longer being actively >> developed, so it is anticipated that they will stop working until somebody >> fixes them (if at all). > > I last used poudriere a couple years back. > It is much more involved than portmaster > (obviously, these 2 tools are not doing the same job) There's definitely more work up-front to set up poudriere. You get the effort back, though, in long-term viability and not having to chase problems up and down the ports tree. >> So no, portmaster isn't going away. But, there's no guarantee that it will >> keep working. We strongly, strongly advise everyone to use poudriere or >> synth to build their ports, and then plain old "pkg upgrade" to handle >> updates. > > because my experience of poudriere was mixed, > I haven't used it at all on amd64. > pkg is great. And when occasionally I need > non-default options I use portmaster. > >> >> The vast majority of problems reported on this mailing list exist only in >> portmaster/portupgrade, because they do not do clean builds. At this point, >> portmaster should only be used by people with enough ports development >> experience to understand and mitigate conflicts and various build errors. > > I agree that a dirty environement is mostly > the source of bad portmaster builds. > > However, to create the whole poudriere enviroment > to build a port a week, or maybe a month, seems > like an overkill. > > Yes, I know, it's a volunteer project, things > evolve, unless somebody steps in... > > If my recollection of poudriere is correct, > I'll need a separate ports tree? > And if I only need to build a single port > with custom settings, I'll have to start > every time from scratch? > And if I want to use this single port with > default settings with my other ports, I need > to make sure the 2 port trees are in sync. > > Sorry if I don't do poudeire justice, it's been a while... You don't need separate port trees. The idea is to use poudriere to build ALL your ports. Just make a list of the ports you want, pass it to poudriere, and it will keep everything up-to-date, rebuild things when they need to be rebuilt, and give you a pkg repository so you can just run "pkg install foo" or "pkg upgrade" to keep your system running. Even if you do use poudriere to build only a few ports, it's pretty easy. Give your own generated packages a higher priority in /usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo above the upstream repo. So no, you don't need separate ports trees. poudriere is happiest though when you let it manage its own ports tree, so I prefer to just symlink /usr/ports to it, but you can very easily use a pre-existing ports tree with poudriere. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
tl/dr at bottom, repeated here, flowchart please On Tue, 5/30/17, Adam Weinberger wrote: Subject: Re: The future of portmaster To: me...@bris.ac.uk Cc: rollingb...@gmail.com, freebsd-ports@freebsd.org Date: Tuesday, May 30, 2017, 7:30 AM > On 30 May, 2017, at 8:15, Anton Shterenlikht wrote: > >> From ad...@adamw.org Tue May 30 15:03:31 2017 >> >> The ports tree continues to evolve. Major new features are planned and in the process of being implemented. These changes will break all the port-building tools. > > oy vei > >> poudriere and synth are actively developed, so they will quickly support the new changes. portmaster and portupgrade are no longer being actively developed, so it is anticipated that they will stop working until somebody fixes them (if at all). > > I last used poudriere a couple years back. > It is much more involved than portmaster > (obviously, these 2 tools are not doing the same job) There's definitely more work up-front to set up poudriere. You get the effort back, though, in long-term viability and not having to chase problems up and down the ports tree. >> So no, portmaster isn't going away. But, there's no guarantee that it will keep working. We strongly, strongly advise everyone to use poudriere or synth to build their ports, and then plain old "pkg upgrade" to handle updates. > > because my experience of poudriere was mixed, > I haven't used it at all on amd64. > pkg is great. And when occasionally I need > non-default options I use portmaster. > >> >> The vast majority of problems reported on this mailing list exist only in portmaster/portupgrade, because they do not do clean builds. At this point, portmaster should only be used by people with enough ports development experience to understand and mitigate conflicts and various build errors. > > I agree that a dirty environement is mostly > the source of bad portmaster builds. > > However, to create the whole poudriere enviroment > to build a port a week, or maybe a month, seems > like an overkill. > > Yes, I know, it's a volunteer project, things > evolve, unless somebody steps in... > > If my recollection of poudriere is correct, > I'll need a separate ports tree? > And if I only need to build a single port > with custom settings, I'll have to start > every time from scratch? > And if I want to use this single port with > default settings with my other ports, I need > to make sure the 2 port trees are in sync. > > Sorry if I don't do poudeire justice, it's been a while... You don't need separate port trees. The idea is to use poudriere to build ALL your ports. Just make a list of the ports you want, pass it to poudriere, and it will keep everything up-to-date, rebuild things when they need to be rebuilt, and give you a pkg repository so you can just run "pkg install foo" or "pkg upgrade" to keep your system running. Even if you do use poudriere to build only a few ports, it's pretty easy. Give your own generated packages a higher priority in /usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo above the upstream repo. So no, you don't need separate ports trees. poudriere is happiest though when you let it manage its own ports tree, so I prefer to just symlink /usr/ports to it, but you can very easily use a pre-existing ports tree with poudriere. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Sorry for the yahoo webclient not quoting the above. If applicable. Leaving aside my wishes for the /usr/ports/MOVED/portmanager *also* eventually back upto speed with portmaster, even as shareware, this poudriere and even synth I think could benefit from a flowchart... right side differing scenarios what one's goals are left and work backwards thru all the things can go wrong, dotted boxes 'errors' and arrows to the solution(s) paths, [ and a third part of this flowchart I just thought of ...] and on the left simple boxes, like one server one lan, two servers two lan, one server a VPN three hundred downstream 'subscriber' clients for the built ports, and any other things, more visually explained than a much longer wiki reading. tl/dr flowchart please ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
On Tue, May 30, 2017 at 7:15 AM, Anton Shterenlikht wrote: > >From ad...@adamw.org Tue May 30 15:03:31 2017 > > > >The ports tree continues to evolve. Major new features are planned and in > the process of being implemented. These changes will break all the > port-building tools. > > oy vei > > >poudriere and synth are actively developed, so they will quickly support > the new changes. portmaster and portupgrade are no longer being actively > developed, so it is anticipated that they will stop working until somebody > fixes them (if at all). > > I last used poudriere a couple years back. > It is much more involved than portmaster > (obviously, these 2 tools are not doing the same job) > > >So no, portmaster isn't going away. But, there's no guarantee that it > will keep working. We strongly, strongly advise everyone to use poudriere > or synth to build their ports, and then plain old "pkg upgrade" to handle > updates. > > because my experience of poudriere was mixed, > I haven't used it at all on amd64. > pkg is great. And when occasionally I need > non-default options I use portmaster. > > > > >The vast majority of problems reported on this mailing list exist only in > portmaster/portupgrade, because they do not do clean builds. At this point, > portmaster should only be used by people with enough ports development > experience to understand and mitigate conflicts and various build errors. > > I agree that a dirty environement is mostly > the source of bad portmaster builds. > > However, to create the whole poudriere enviroment > to build a port a week, or maybe a month, seems > like an overkill. > > Yes, I know, it's a volunteer project, things > evolve, unless somebody steps in... > > If my recollection of poudriere is correct, > I'll need a separate ports tree? > And if I only need to build a single port > with custom settings, I'll have to start > every time from scratch? > And if I want to use this single port with > default settings with my other ports, I need > to make sure the 2 port trees are in sync. > > Sorry if I don't do poudeire justice, it's been a while... > > Anton > ___ > 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" > I really suggest that you look at synth. It also builds in a clean environment and provides all of the advantages of poudeire for use in a single-system (or multiple identical systems) case. No jails to set up. It builds a local pkg repository and you then use pkg on everything. I don't consider it a replacement for portmaster, but in most environments it does the same job and, since it builds in a clean environment, it avoids many of the issues with other tools. It is also very well documented, so it is not too hard to understand setup and use. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
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 +-+ math/giacxcas | 1.2.2-57| 1.2.3-47 +-+ math/rpy2 | 2.7.8 | 2.8.6 +-+ misc/qt5ct | 0.32| 0.33 +-+ multimedia/mkclean | 0.8.7 | 0.8.9 +-+ 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"
gcc5 not building on 11-0-RELEASE
Hi everyone: I am trying to build lang/gcc5 using Poudriere from ports tree just updated a couple of hours ago. The port fails to link with: /usr/local/bin/ld: /wrkdirs/usr/ports/lang/gcc5/work/.build/./gcc/liblto_plugin.so: error loading plugin: Service unavailable My port options are: ---Begin OPTIONS List--- ===> The following configuration options are available for gcc5-5.4.0_2: BOOTSTRAP=off: Build using a full bootstrap GRAPHITE=on: Support for Graphite loop optimizations JAVA=off: Java platform support ===> Use 'make config' to modify these settings ---End OPTIONS List--- Some more info about my system: >> Building lang/gcc5 build started at Tue May 30 17:59:55 CEST 2017 port directory: /usr/ports/lang/gcc5 building for: FreeBSD jaguar-default-job-01 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 #0: Tue Apr 11 08:48:40 UTC 2017 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 maintained by: ger...@freebsd.org Makefile ident: $FreeBSD: head/lang/gcc5/Makefile 441905 2017-05-28 09:31:40Z gerald $ Poudriere version: 3.1.14 Host OSVERSION: 1100122 Jail OSVERSION: 1100122 ---Begin Environment--- SHELL=/bin/csh STATUS=1 OPSYS=FreeBSD ARCH=amd64 SAVED_TERM=rxvt MASTERMNT=/usr/local/poudriere/data/.m/jaguar-default/ref UID=0 FORCE_PACKAGE=yes PATH=/usr/local/libexec/poudriere:.:/home/elferdo/local/bin:/usr/local/share/spark/bin:/home/elferdo/.cargo/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+ POUDRIERE_BUILD_TYPE=bulk PKGNAME=gcc5-5.4.0_2 OSREL=11.0 _OSRELEASE=11.0-RELEASE-p9 PYTHONBASE=/usr/local OLDPWD=/ _SMP_CPUS=12 PWD=/usr/local/poudriere/data/.m/jaguar-default/ref/.p/pool HAVE_COMPAT_IA32_KERN=YES MASTERNAME=jaguar-default SCRIPTPREFIX=/usr/local/share/poudriere _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun USER=root HOME=/root POUDRIERE_VERSION=3.1.14 SCRIPTPATH=/usr/local/share/poudriere/bulk.sh CONFIGURE_MAX_CMD_LEN=262144 LIBEXECPREFIX=/usr/local/libexec/poudriere LOCALBASE=/usr/local PACKAGE_BUILDING=yes _JAVA_OS_LIST_REGEXP=native\|linux OSVERSION=1100122 ---End Environment--- Thanks for your help. Best, Fernando ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
> The ports tree continues to evolve. Major new features are planned and in the > process of being implemented. These changes will break all the port-building > tools. > poudriere and synth are actively developed, so they will quickly support the > new changes. portmaster and portupgrade are no longer being actively > developed, so it is anticipated that they will stop working until somebody > fixes > them (if at all). > So no, portmaster isn't going away. But, there's no guarantee that it will > keep working. We strongly, strongly advise everyone to use poudriere or synth > to build their ports, and then plain old "pkg upgrade" to handle updates. > The vast majority of problems reported on this mailing list exist only in > portmaster/portupgrade, because they do not do clean builds. At this point, > portmaster should only be used by people with enough ports development > experience to understand and mitigate conflicts and various build errors. # Adam > Adam Weinberger I remember the days when some FreeBSD users swore by portmanager, but subsequent changes to ports framework rendered portmanager unworkable. I never used portmanager. I used portupgrade but switched to portmaster. First attempt to build synth failed on FreeBSD-current when the system crashed and rebooted as I was sleeping, so maybe not synth's fault. Now I see it might be impossible to build synth on FreeBSD-current due to some ports, including lang/gcc5-aux and lang/gcc6-aux, not building following the change to ino64; lang/gcc6-aux is a dependency of synth. But I suppose this will be patched, hopefully in the near future. I noticed that synth was ported to NetBSD along with pkg, but see nothing on NetBSD emailing lists regarding synth. Maybe synth is not catching on in NetBSD; pkgsrc users seem to be staying with pkg_* tools like in FreeBSD before the switch to pkgng. Big nuisance updating packages whose names have changed. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
On Tue, 30 May 2017, Adam Weinberger wrote: You don't need separate port trees. The idea is to use poudriere to build ALL your ports. Just make a list of the ports you want, pass it to poudriere, and it will keep everything up-to-date, rebuild things when they need to be rebuilt, and give you a pkg repository so you can just run "pkg install foo" or "pkg upgrade" to keep your system running. Even if you do use poudriere to build only a few ports, it's pretty easy. Give your own generated packages a higher priority in /usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo above the upstream repo. Where is this seemingly super easy process documented? Yes, I can read the docs and try to figure out the "best practice" workflow, or someone with amazing knowledge of poudriere (and/or synth) can write a "here's how to manage your ports" best practices for the occasional sysadmin, rather than the hard-core supporting a fleet of FreeBSD boxes admin. I've looked before and never found such a document. Something from the portupgrade or portmaster user POV, and why and how to move to the more modern and actively developed tools. So no, you don't need separate ports trees. poudriere is happiest though when you let it manage its own ports tree, so I prefer to just symlink /usr/ports to it, but you can very easily use a pre-existing ports tree with poudriere. You make it sound so easy! Maybe it is, but I haven't found it. Beckman --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ --- ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
> On 30 May, 2017, at 11:37, Peter Beckman wrote: > > On Tue, 30 May 2017, Adam Weinberger wrote: > >> You don't need separate port trees. The idea is to use poudriere to build >> ALL your ports. Just make a list of the ports you want, pass it to >> poudriere, and it will keep everything up-to-date, rebuild things when >> they need to be rebuilt, and give you a pkg repository so you can just >> run "pkg install foo" or "pkg upgrade" to keep your system running. >> >> Even if you do use poudriere to build only a few ports, it's pretty easy. >> Give your own generated packages a higher priority in >> /usr/local/etc/pkg/repos/ and you can transparently layer your pkg repo >> above the upstream repo. > > Where is this seemingly super easy process documented? Yes, I can read the > docs and try to figure out the "best practice" workflow, or someone with > amazing knowledge of poudriere (and/or synth) can write a "here's how to > manage your ports" best practices for the occasional sysadmin, rather than > the hard-core supporting a fleet of FreeBSD boxes admin. > > I've looked before and never found such a document. Something from the > portupgrade or portmaster user POV, and why and how to move to the more > modern and actively developed tools. /usr/local/etc/pkg/repos/local.conf: Local: { url:file:///zroot/poudriere/data/packages/JAILNAME, priority: 10 } Then, "pkg install foo" will first look for foo in your generated packages, and fall back to the upstream pkg repository. If you use poudriere to build all your ports, just add this to turn upstream off entirely: /usr/local/etc/pkg/repos/FreeBSD.conf: FreeBSD: { enabled: no } >> So no, you don't need separate ports trees. poudriere is happiest though >> when you let it manage its own ports tree, so I prefer to just symlink >> /usr/ports to it, but you can very easily use a pre-existing ports tree >> with poudriere. > > You make it sound so easy! Maybe it is, but I haven't found it. Check out https://github.com/freebsd/poudriere/wiki/use_system_ports_tree for some instructions on how to use a system ports tree. Personally, I prefer to let poudriere's tree be the main one: ( Remove your old ports tree first; keep the distfiles around if you'd like) # poudriere ports -c (Skip this if you already created a poudriere tree) # ln -s /zroot/poudriere/ports/default /usr/ports # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: gcc5 not building on 11-0-RELEASE
On 30 May 2017, at 19:19, Fernando Herrero Carrón wrote: > > Hi everyone: > > I am trying to build lang/gcc5 using Poudriere from ports tree just updated > a couple of hours ago. > > The port fails to link with: > > /usr/local/bin/ld: > /wrkdirs/usr/ports/lang/gcc5/work/.build/./gcc/liblto_plugin.so: error > loading plugin: Service unavailable This is usually the message you get when static executables attempt to use dlopen(). Did you manage to link /usr/local/bin/ld as a static executable? -Dimitry signature.asc Description: Message signed with OpenPGP
RE: The future of portmaster [and of ports-mgmt/synth]
Adam Weinberger adamw at adamw.org wrote on Tue May 30 14:00:21 UTC 2017: > poudriere and synth are actively developed Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017 > I really suggest that you look at synth. ports-mgmt/synth depends on lang/gcc6-aux which has lost its maintainer --and is broken for FreeBSD head after the ino64 changes. (synth was written in ada --which is not directly available from the normal lang/gcc* 's.) This broken status includes amd64 now. (The lang/gcc6-aux maintainer was also the author/creator.) A similar status happened for ports-mgmt/synth relative to its newly claimed aarch64 support: lang/gcc6-aux turned out to be broken such that it would not build on aarch64, which in turn stopped ports-mgmt/synth builds. . . ports-mgmt/synth -r437524 (Sun Apr 2) reported: > ports-mgmt/synth: update 1.68 -> 1.69 > > - FreeBSD/ARM* support but by the time I tried I could not build it because I could not build lang/gcc6-aux on a Pine64+ 2GB: head's system headers vs. gcc munging of copies them were no longer matched in the bootstrap process that lang/gcc6-aux uses. This is still true even without progressing to the ino64 changes in FreeBSD's head (12-CURRENT). Unfortunately ports-mgmt/synth suffers from build prerequisites that do not have a wide range of contributing maintainers or otherwise broad support. This looks like it will make ports-mgmt/synth problematical as things are. === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[t...@iki.fi: v2.2.30 released]
Heads up! - Forwarded message from Timo Sirainen - Date: Tue, 30 May 2017 21:16:31 +0300 From: Timo Sirainen To: dovecot-n...@dovecot.org, Dovecot Mailing List Subject: v2.2.30 released X-Mailer: Apple Mail (2.3273) https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig * auth: Use timing safe comparisons for everything related to passwords. It's unlikely that these could have been used for practical attacks, especially because Dovecot delays and flushes all failed authentications in 2 second intervals. Also it could have worked only when passwords were stored in plaintext in the passdb. * master process sends SIGQUIT to all running children at shutdown, which instructs them to close all the socket listeners immediately. This way restarting Dovecot should no longer fail due to some processes keeping the listeners open for a long time. + auth: Add passdb { mechanisms=none } to match separate passdb lookup + auth: Add passdb { username_filter } to use passdb only if user matches the filter. See https://wiki2.dovecot.org/PasswordDatabase + dsync: Add dsync_commit_msgs_interval setting. It attempts to commit the transaction after saving this many new messages. Because of the way dsync works, it may not always be possible if mails are copied or UIDs need to change. + imapc: Support imapc_features=search without ESEARCH extension. + imapc: Add imapc_features=fetch-bodystructure to pass through remote server's FETCH BODY and BODYSTRUCTURE. + imapc: Add quota=imapc backend to use GETQUOTA/GETQUOTAROOT on the remote server. + passdb imap: Add allow_invalid_cert and ssl_ca_file parameters. + If dovecot.index.cache corruption is detected, reset only the one corrupted mail instead of the whole file. + doveadm mailbox status: Add "firstsaved" field. + director_flush_socket: Add old host's up/down and vhost count as parameters - More fixes to automatically fix corruption in dovecot.list.index - dsync-server: Fix support for dsync_features=empty-header-workaround - imapc: Various bugfixes, including infinite loops on some errors - IMAP NOTIFY wasn't working for non-INBOX if IMAP client hadn't enabled modseq tracking via CONDSTORE/QRESYNC. - fts-lucene: Fix it to work again with mbox format - Some internal error messages may have contained garbage in v2.2.29 - mail-crypt: Re-encrypt when copying/moving mails and per-mailbox keys are used. Otherwise the copied mails can't be opened. - vpopmail: Fix compiling - End forwarded message - -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism UK Stop Theresa MAy MT V2 and Impotent Corbyn, Vote Farron and LDEm!! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster [and of ports-mgmt/synth]
On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote: > Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017 > > > I really suggest that you look at synth. synth is currently only available for x86 and unless someone steps up to do the work to make the Ada compilers run on the other architectures that is certain to remain to the case. 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: texinfo build failure
Anyone care to address this? On 5/26/17 2:41 PM, Michael Butler wrote: Is anyone else seeing this failure to build texinfo on -CURRENT? cd doc && gmake TEXMF=/usr/local/share/texmf install-tex gmake[3]: Entering directory '/usr/ports/print/texinfo/work/texinfo-6.3/doc' test -n "/usr/local/share/texmf" || (echo "TEXMF must be set." >&2; exit 1) /bin/sh /usr/ports/print/texinfo/work/texinfo-6.3/build-aux/install-sh -d /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/generic/epsf install -m 0644 ./texinfo.tex /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo/texinfo.tex install -m 0644 ./epsf.tex /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/generic/epsf/epsf.tex for f in txi-ca.tex txi-cs.tex txi-de.tex txi-en.tex txi-es.tex txi-fr.tex txi-hu.tex txi-is.tex txi-it.tex txi-ja.tex txi-nb.tex txi-nl.tex txi-nn.tex txi-pl.tex txi-pt.tex txi-ru.tex txi-sr.tex txi-tr.tex txi-uk.tex; do \ install -m 0644 ./$f /usr/ports/print/texinfo/work/stage/usr/local/share/texmf/tex/texinfo/$f; done gmake[3]: Leaving directory '/usr/ports/print/texinfo/work/texinfo-6.3/doc' gmake[2]: Leaving directory '/usr/ports/print/texinfo/work/texinfo-6.3' install -m 0644 /usr/ports/distfiles/texinfo/6.3/htmlxref.cnf /usr/ports/print/texinfo/work/stage/usr/local/share/texinfo /bin/rmdir /usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo rmdir: /usr/ports/print/texinfo/work/stage/usr/local/lib/texinfo: No such file or directory *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/texinfo *** Error code 1 Stop. make: stopped in /usr/ports/print/texinfo ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20170526-91663-1k3i9m0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=texinfo-6.3_1,1 UPGRADE_PORT_VER=6.3_1,1 make ** Fix the problem and try again. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
One thing I forgot to mention in my last post is that the UPDATING file looks geared to portmaster and portupgrade. Users are thus led to believe that portupgrade and portmaster are still the currently recommended tools. If the ports people want to get users to switch to synth or poudriere, updating instructions should include synth and poudriere. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
> On 30 May, 2017, at 14:19, Thomas Mueller wrote: > > > One thing I forgot to mention in my last post is that the UPDATING file looks > geared to portmaster and portupgrade. > > Users are thus led to believe that portupgrade and portmaster are still the > currently recommended tools. > > If the ports people want to get users to switch to synth or poudriere, > updating instructions should include synth and poudriere. There are no updating instructions for them. They do the right thing automatically. Only portmaster needs its hand held every time something gets updated. The only difference is that things go into a make.conf in /usr/local/etc/poudriere.d/ rather than /etc/make.conf (see CUSTOMISATION in poudriere(8) for details), and I don't know if synth has a special place for it too. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Owncloud upgrade failure
Hi, After updating owncloud from the early 10.0.1 package, the upgrading process failed on the following: root:/<1>local/www/owncloud#sudo -u www php occ upgrade The process control (PCNTL) extensions are required in case you want to interrupt long running commands - see http://php.net/manual/en/book.pcntl.php ownCloud or one of the apps require upgrade - only a limited number of commands are available You may use your browser or the occ upgrade command to do the upgrade Set log level to debug Updating database schema Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE TABLE oc_account_terms (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, account_id BIGINT UNSIGNED NOT NULL, term VARCHAR(256) NOT NULL, INDEX account_id_index (account_id), INDEX term_index (term), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes Update failed Maintenance mode is kept active Reset log level Any clue to get this working again ? -- David Marec https://lapinbilly.eu/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster
On Tue, 2017-05-30 at 14:25 -0600, Adam Weinberger wrote: > > On 30 May, 2017, at 14:19, Thomas Mueller > > wrote: > > > > > > One thing I forgot to mention in my last post is that the UPDATING > > file looks geared to portmaster and portupgrade. > > > > Users are thus led to believe that portupgrade and portmaster are > > still the currently recommended tools. > > > > If the ports people want to get users to switch to synth or > > poudriere, updating instructions should include synth and > > poudriere. > > There are no updating instructions for them. They do the right thing > automatically. Only portmaster needs its hand held every time > something gets updated. > > The only difference is that things go into a make.conf in > /usr/local/etc/poudriere.d/ rather than /etc/make.conf (see > CUSTOMISATION in poudriere(8) for details), and I don't know if synth > has a special place for it too. > And not only that, but poudriere reads MOVED as well. > -- Jim Ohlstein Professional Mailman Hosting https://mailman-hosting.com/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [t...@iki.fi: v2.2.30 released]
On Tue, 2017-05-30 at 14:02 -0600, The Doctor wrote: > Heads up! How about submitting a patch for the upgrade? That would be helpful. https://bugs.freebsd.org/bugzilla/ > > - Forwarded message from Timo Sirainen - > > Date: Tue, 30 May 2017 21:16:31 +0300 > From: Timo Sirainen > To: dovecot-n...@dovecot.org, Dovecot Mailing List rg> > Subject: v2.2.30 released > X-Mailer: Apple Mail (2.3273) > > https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz > https://dovecot.org/releases/2.2/dovecot-2.2.30.tar.gz.sig > > * auth: Use timing safe comparisons for everything related to >passwords. It's unlikely that these could have been used for >practical attacks, especially because Dovecot delays and flushes > all >failed authentications in 2 second intervals. Also it could have >worked only when passwords were stored in plaintext in the passdb. > * master process sends SIGQUIT to all running children at shutdown, >which instructs them to close all the socket listeners > immediately. >This way restarting Dovecot should no longer fail due to some >processes keeping the listeners open for a long time. > > + auth: Add passdb { mechanisms=none } to match separate passdb > lookup > + auth: Add passdb { username_filter } to use passdb only if user >matches the filter. See https://wiki2.dovecot.org/PasswordDatabase > + dsync: Add dsync_commit_msgs_interval setting. It attempts to > commit >the transaction after saving this many new messages. Because of > the >way dsync works, it may not always be possible if mails are copied >or UIDs need to change. > + imapc: Support imapc_features=search without ESEARCH extension. > + imapc: Add imapc_features=fetch-bodystructure to pass through > remote >server's FETCH BODY and BODYSTRUCTURE. > + imapc: Add quota=imapc backend to use GETQUOTA/GETQUOTAROOT on the >remote server. > + passdb imap: Add allow_invalid_cert and ssl_ca_file parameters. > + If dovecot.index.cache corruption is detected, reset only the one >corrupted mail instead of the whole file. > + doveadm mailbox status: Add "firstsaved" field. > + director_flush_socket: Add old host's up/down and vhost count as > parameters > - More fixes to automatically fix corruption in dovecot.list.index > - dsync-server: Fix support for dsync_features=empty-header- > workaround > - imapc: Various bugfixes, including infinite loops on some errors > - IMAP NOTIFY wasn't working for non-INBOX if IMAP client hadn't >enabled modseq tracking via CONDSTORE/QRESYNC. > - fts-lucene: Fix it to work again with mbox format > - Some internal error messages may have contained garbage in v2.2.29 > - mail-crypt: Re-encrypt when copying/moving mails and per-mailbox > keys >are used. Otherwise the copied mails can't be opened. > - vpopmail: Fix compiling > > - End forwarded message - > -- Jim Ohlstein Professional Mailman Hosting https://mailman-hosting.com/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [t...@iki.fi: v2.2.30 released]
On Tue, May 30, 2017 at 04:53:23PM -0400, Jim Ohlstein wrote: > On Tue, 2017-05-30 at 14:02 -0600, The Doctor wrote: > > Heads up! > > How about submitting a patch for the upgrade? That would be helpful. > > https://bugs.freebsd.org/bugzilla/ > Adam Weinberger (Maintainer) already updated the port in the tree. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster [and of ports-mgmt/synth]
On 30 May 2017 at 15:00, Mark Millard wrote: > > ports-mgmt/synth depends on lang/gcc6-aux For reference, I've created PR 219667 to track the lang/gcc6-aux issue. The pre-built bootstrap compilers need to be recreated I believe, with a trick similar to the one used for lang/ghc. ___ 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: Owncloud upgrade failure
Le 30.05.2017 à 22:29, David Marec a écrit : CREATE TABLE oc_account_terms (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, account_id BIGINT UNSIGNED NOT NULL, term VARCHAR(256) NOT NULL, INDEX account_id_index (account_id), INDEX term_index (term), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB' An attempt to feed this to mysql using the command line tool triggers the same error. With or without the 'ENGINE' clause. -- David Marec https://lapinbilly.eu/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster [and of ports-mgmt/synth]
On 2017-05-30 22:06, Mark Linimon wrote: On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote: Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017 I really suggest that you look at synth. synth is currently only available for x86 and unless someone steps up to do the work to make the Ada compilers run on the other architectures that is certain to remain to the case. Hello, I have not followed this thread before but just wanted to say that I use portmaster extensively, it works for us and I would miss it if it went. Are there actually plans to retire it? Hope I didn't miss something. Just my $0.02... //per ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster [and of ports-mgmt/synth]
On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote: > Hello, I have not followed this thread before but just wanted to say > that I use portmaster extensively, it works for us and I would miss > it if it went. Are there actually plans to retire it? To reiterate the status: * some extensive changes to the ports framework are coming; * these will require large changes to all the port upgrade tools; * no one has stepped forwards to offer to do the work for anything other than poudriere AFAIK. If no one does the work, at the time the large changes come, the other tools will break. People have been wanting subpackages (aka flavors) for many years; IIUC these are parts of the changes that are coming. Someone needs to step forwards and say "yes, I will do the work." 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: Owncloud upgrade failure
Le 30.05.2017 à 22:29, David Marec a écrit : Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'CREATE TABLE oc_account_terms (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, account_id BIGINT UNSIGNED NOT NULL, term VARCHAR(256) NOT NULL, INDEX account_id_index (account_id), INDEX term_index (term), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = InnoDB': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes Update failed Maintenance mode is kept active Reset log level Any clue to get this working again ? As I understand the issue, the 'term' field stores too many bytes - VARCHAR(256) * UTF8 > 767 ? - to be used as a key index !? (255 seems to be ok ) -- David Marec https://lapinbilly.eu/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: The future of portmaster [and of ports-mgmt/synth]
On Tue, May 30, 2017 at 2:53 PM, Mark Linimon wrote: > On Tue, May 30, 2017 at 11:46:46PM +0200, Per olof Ljungmark wrote: > > Hello, I have not followed this thread before but just wanted to say > > that I use portmaster extensively, it works for us and I would miss > > it if it went. Are there actually plans to retire it? > > To reiterate the status: > > * some extensive changes to the ports framework are coming; > * these will require large changes to all the port upgrade tools; > * no one has stepped forwards to offer to do the work for anything >other than poudriere AFAIK. > > If no one does the work, at the time the large changes come, the > other tools will break. > > People have been wanting subpackages (aka flavors) for many years; > IIUC these are parts of the changes that are coming. > > Someone needs to step forwards and say "yes, I will do the work." > > mcl Since portmaster is still popult and since the only solutions that looks to be available in the near term are pouderiere or raw make, neither terribly viable for many, I will look into updating portmaster to deal with 'flavors'. This looks fairly straight forward and I my have the sh capability to manage it. (And then again, I am far from a great shell person, so I may well be wrong.) I have looked at Doug's script and it is pretty readable, but writing may require help. Can someone point me where to look for documentation on flavors? I have poked around the wiki, but to no avail. Unless there is documentation on what needs to be done, doing it will be hopeless and waiting for the packaging system to updated means portmaster WILL be broken for some period of time. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Bug 218703 for graphics/blender has patches that should be commited
Hello, Bug 218703 for graphics/blender has patches which fixes a known problem. However graphics/blender does not have a maintainer, so no-one has commited the patches. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218703 Please commit said patches, thanks :) Erik Nordstrø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 future of portmaster [and of ports-mgmt/synth]
On 2017-May-30, at 1:06 PM, Mark Linimon wrote: > On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote: >> Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017 >> >>> I really suggest that you look at synth. > > synth is currently only available for x86 and unless someone steps up > to do the work to make the Ada compilers run on the other architectures > that is certain to remain to the case. As I understand currently x86 and amd64 are also broken for lang/gcc6-aux if built from a recent enough head (ino64). True historically (x86/amd64) but briefly there was a little more, at least for a native aarch64 context if I understand right. (Possibly armv6 and/or armv7 too?) My understanding is that there was a short time when aarch64 also had Ada going via lang/gcc6-aux . But the problem of gcc's technique of adjusting system headers so it has separate copies (supposedly to force the headers to be language complaint) vs. FreeBSD making updates to various headers that has gcc copied and adjusted broke the bootstrap compiler's ability to do the bootstrap. (A compiler involved in the bootstrap for aarch64 is actually retrieved from elsewhere as part of the build as I remember. But it processes the headers that are as of when the bootstrap compiler was built and made its adjustments.) In other words: the overall mechanism (FreeBSD+gcc) is fragile and both sides tend to think that the other side should be the one to change how they work in order to remove the fragile status. The two parts just do not fit well and no minor variations in how the two operate can remove the mismatch. I happened to do my attempted experiment that involved building ports-mgmt/synth on aarch64 after things had broken. (I did not try armv6/v7 but there might have been a short time when there was context in that area that worked as well.) aarch64 (and any others) did not last long. Powerpc, powerpc64, mips, etc. have never attempted for Ada support as far as know. === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"