Re: portmaster new development
On 28.12.2020 16:16, Stefan Esser wrote: Am 28.12.20 um 11:11 schrieb abi via freebsd-ports:> I build my ports in poudriere in VM without zfs or ssd on pre-Sandy Bridge CPU. I don't have enough memory or disk space, so I don't use tmpfs or ccache either. I migrated from portmaster when it was abandoned several years ago and don't think I'll come back, especially if new portmaster will be written on bash. The idea behind portmaster was zero dependencies, so it doesn't brake after major upgrades. You are free to use poudriere and it definitely is the official tool for FreeBSD package building (and I have to use it myself and it has cost me a lot of time rebuilding broken poudriere jails and keeping them in state that I can use them to test new ports on a number of different releases as well as i386 plus amd64). And while you are free to never again use portmaster, telling people that it has been abandoned is just a _lie_ and I'd want to ask you to stop telling it. It has been continuously maintained for decades. I remember portmaster marked as deprecated in 2016. I've switched to poudriere because of that. So, it _was_ abandoned when I migrated. It is good that it is not, the more options - the better. But some people here telling that poudriere requires ZFS and powerful dedicated hardware, I just pointed that they are wrong. ___ 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: portmaster new development
On 28.12.2020 12:44, David Gessel wrote: Original Message Subject: Re: portmaster new development From: LuMiWa via freebsd-ports To: freebsd-ports@freebsd.org Date: 2020-12-27 02:00+0300 On Sun, 27 Dec 2020 11:16:23 +0100 Michael Grimm wrote: Matthias Apitz wrote: El día domingo, diciembre 27, 2020 a las 09:22:42a. m. +0100, Kurt Jaeger escribió: That works as well. I have a checkout of the ports tree, use make config to define non-default port options. This stores the selected OPTIONs in /var/db/ports/, and poudriere uses those options just fine. Re/ the options, I copy them into the jail with something like this procedure: # cd /usr/ports/mail/mutt # make config # mkdir -p /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt # cp /var/db/ports/mail_mutt/options /usr/local/etc/poudriere.d/freebsd-head-options/mail_mutt 'freebsd-head' is the name of the poudriere jail (I have some of them) and the ports options stay there, as well the make.conf options in /usr/local/etc/poudriere.d/freebsd-head-make.conf I am following stable, and my jail's name has been set to stable. All of poudriere's settings/configs are kept in: /usr/local/etc/poudriere.d The subject is 'portmaster new development' but again start pushing poudriere to FreeBSD users. I do not use zfs file system and I do not use poudriere and I do not want to use on my computer for building some ports and then spending hours and hours with poudriere with not enough machine. For me is portmaster perfect as is now. I have to agree, portmaster works for certain user cases where poudriere doesn't, like mine. The answer seems to be just (buy) a high end machine and dedicate it to build with lots of RAM, high end CPU's, and a big ZFS array with the right combination of SSDs etc and it is fast and stable! I build my ports in poudriere in VM without zfs or ssd on pre-Sandy Bridge CPU. I don't have enough memory or disk space, so I don't use tmpfs or ccache either. I migrated from portmaster when it was abandoned several years ago and don't think I'll come back, especially if new portmaster will be written on bash. The idea behind portmaster was zero dependencies, so it doesn't brake after major upgrades. ___ 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: Sudden trouble with net/rdesktop
On 12.11.2020 19:12, Yuri Pankov wrote: Andrea Venturoli wrote: Hello. After many year of happy usage, since yesterday rdesktop dumps core (12.2/amd64). % rdesktop xx Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file utils.c, line 499. Abort (core dumped) This is systematic with 4 servers out of 5; the 5th still works perfectly, but I have no idea in which way it might differ from the others. I don't think this has anything to do with the upgrade to 1.9.0, since I was able to use 1.9.0 for a while. Anyone else seeing this? Where do I go and look? I see a similar report on github: https://github.com/rdesktop/rdesktop/issues/380 Could it be something that changed on remote side, e.g. any recent updates? As a workaround, try increasing the buf size to e.g. 512 in utils.c:_utils_cert_get_info(). I have the same problem, however I'm sure that nothing has changed on remote side (Windows Update is completely disabled). I updated my FreeBSD workstation though to 12.2 and all ports. ___ 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"
Zoneminder update: looking for a committer
Hello, looking for a committer for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250234 @lwhsu had pointed me to some issues, however he didn't reply after I fixed them. ___ 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: Is IPV6 option still necessary?
09.10.2019 09:15, Baptiste Daroussin пишет: I'm writing from 2019 and I build kernel and ports without IPv6. For all this years I fail to understand why I need it. My home devices fit 10.0.0.0/16 nicely, I have faith in NAT and I encountered no IPv6-only sites. But I saw CVEs in IPv6 stack. Plenty of FreeBSD things are ipv6 only in the FreeBSD cluster. In particular if you do look at the build machines in the cluster, no ipv6 will mean no access to the build log in case of failures. I agree I don't see the reason why we should keep that ipv6 option. When off this option does not bring much value to the users as the code for apps to support ipv6 mostly reside in the libc. Actually that was my intent in 2012 to first turn it on by default everywhere and then drop the option entirely. Are you going to keep IPv6 kernel option? If off and ports can detect ipv6 availability in runtime, I don't see problem at all. ___ 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: Is IPV6 option still necessary?
07.10.2019 09:18, Yasuhiro KIMURA пишет: On October 10, 2012 IPV6 option of all ports was enabled by default. Commit message said "We are in 2012, it is time to activate IPV6 options by default everywhere". And now we are in 2019. IPv6 is more widely used than 2012. So I wonder if IPV6 option is still necessary. If you use official packages then you always use IPv6-enabled binaries. And even if you build packages by yourself you still use IPv6-enabled ones unless you disable IPV6 option. So I think at most only a few people uses IPv6-disabled packages. Are there anybody who still disables IPV6 option for some serious reason such as working around IPv6-related problem? If there aren't then I think it's time to remove IPV6 option from ports framework. I'm writing from 2019 and I build kernel and ports without IPv6. For all this years I fail to understand why I need it. My home devices fit 10.0.0.0/16 nicely, I have faith in NAT and I encountered no IPv6-only sites. But I saw CVEs in IPv6 stack. ___ 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"
