Re: go modules fetching problem
Hi, First it is nice that you have working ipv6 now. 👍 But I'm still surprised that the download of distfiles choose the IPv6 address while you did not have IPv6 enabled. This port uses some golang code to fetch the file: 47794 0 S+ 0:00.04 | | `-- make fetch 47899 0 S+ 0:03.71 | | `-- /usr/local/bin/go119 mod download -x all (go) And the download site has both IPv4 and IPv6 configured. $ host proxy.golang.com proxy.golang.com has address 172.217.168.241 proxy.golang.com has IPv6 address 2a00:1450:400e:802::2011 ... These addresses change now and than so it looks like a pool of servers. The go code seems to have logic to handle the dualstack situation and prefer ipv4 over ipv6 (as far as I understand the code). https://github.com/golang/go/blob/0f6ee42fe063a48d7825bc03097bbb714aafdb7d/src/net/dial.go#L421 So a possibility for the cause of the problem can be that a server in the pool was not reachable by ipv4 which made the go code fall back to ipv6. This idea is also strengthened by the fact that the first couple of downloads succeeded. If you want to dive deeper you might cc the g...@freebsd.org mailinglist. Regards, Ronald. Van: Nuno Teixeira Datum: zaterdag, 6 augustus 2022 18:45 Aan: Larry Rosenman CC: Ronald Klop , FreeBSD Mailing List Onderwerp: Re: go modules fetching problem Hi Larry, That's a possibility and as always they never notify clients about changes. Before I switched to ipv6 on local machine I've tried to disable router ipv6 but thats not possible because there is no option to configured it on web interface nor cmd line interface: --- /cli> lan/ipv6/show +-+ |LAN IPV6 | +++ |IPv6|Status | +++ |Enabled |Up | +++ --- I'm happy that I'm using ipv6 for the first time :) Cheers and thanks, Larry Rosenman escreveu no dia sábado, 6/08/2022 à(s) 16:46: Is it possible your ISP just enabled IPv6? On 08/06/2022 10:34 am, Nuno Teixeira wrote: Hello, I've found a fix: configure ethernet to ipv6 --- ifconfig_re0="DHCP" ifconfig_re0_ipv6="inet6 accept_rtadv" rtsold_enable="YES" --- This is very strange because I've never used ipv6 before, and until a couple days 14 current was running fine in ipv4 using re0/iwlwifi0. Maybe something change in CURRENT? I'm at latest 1ffd352bc25b Now I need to find a way of using ipv6 on iwlwifi0 because it crashes using "ifconfig_wlan0_ipv6="inet6 accept_rtadv"... Thanks, Nuno Teixeira escreveu no dia sábado, 6/08/2022 à(s) 11:58: Hi Ronald, I don't use ipv6. --- wlan0: flags=8843 metric 0 mtu 1500 ether 6c:6a:77:df:09:21 inet 192.168.1.65 netmask 0xff00 broadcast 192.168.1.255 groups: wlan ssid MEO-3637C0 channel 60 (5300 MHz 11a) bssid 00:06:91:36:37:c1 regdomain ETSI country PT authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit txpower 24 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 wme roaming MANUAL parent interface: iwlwifi0 media: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11a status: associated nd6 options=29 --- Ronald Klop escreveu no dia sábado, 6/08/2022 à(s) 10:49: You get an ipv6 address for the host. But the host is not reachable. " dial tcp [2a00:1450:4003:80c::2011]:443: conn ect: no route to host" Is ipv6 properly configured in your network? Regards, Ronald Van: Nuno Teixeira Datum: 6 augustus 2022 00:16 Aan: FreeBSD Mailing List Onderwerp: Re: go modules fetching problem (...) Same with poudriere testport, but after some tries modules fetch is complete. Nuno Teixeira escreveu no dia sexta, 5/08/2022 à(s) 22:31: Hello, For the first time I can't fetch go modules from a port. I've tried several ports that uses go:modules and problem is the same. What could be the problem? --- $ make distclean makesum: ===> Cleaning for gomplate-3.11.2 ===> Cleaning Go module cache ===> Deleting distfiles for gomplate-3.11.2 ===> License MIT accepted by the user ===> License MIT accepted by the user ===> gomplate-3.11.2 depends on file: /usr/local/sbin/pkg - found ===> gomplate-3.11.2 depends on file: /usr/local/bin/go119 - found ===> gomplate-3.11.2 depends on package: ca_root_nss>0 - found => v3.11.2.mod doesn't seem to exist in /tmp/go/sysutils_gomplate/gomplate-v3.11.2. => Attempting to fetch https://proxy.golang.org/github.com/hairyhenderson/gomplate/v3/@v/v3.11.2.mod v3.11.2.mod 7063 B 51 MBps00s => v3.11.2.zip doesn't seem to exist in /tmp/go/sysutils_gomplate/gomplate-v3.11.2. => Attempting to fetch https://proxy.golang.org/github.com/hairyhenderson/gomplate/v3/@v/v3.11.2.zip v3.11.2.zip671 kB 6855 kBps00s ===> Fetching all distfiles required by gomplate-3.11.2 for building ===> Fetching
Re: Why NOARCH packages aren't available on all architectures?
On 06/08/2022 07:51, Yuri wrote: On 8/5/22 13:19, Mark Millard wrote: Part of what is going on is that having a NOARCH end result can still involve the build using build-environment-ARCH specific toolchains. You are implying that NOARCH packages should be built on each architecture individually. But NOARCH packages fit any architecture, regardless of where they are built. Once successfully built on one architecture they should become available for all architectures. It's amazing that this isn't what is happening. That's what was intended to happen when "NOARCH" was introduced, but no-one has yet managed to rework our package build system so that NOARCH packages can be shared across all of the repositories for all of the different architectures we support, rather than building them repeatedly. It's simply an optimization we haven't implemented yet. Cheers, Matthew
Re: MegaCLI port is ports-only -- how would you deploy it?
On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote: |03.08.2022, 02:07, "Dan Mahoney" : | Hey there all, | At the dayjob we have a fleet of Dell Poweredge servers that can use | either mptsas or mrsas -- if you use mptsas, you use mptutil (in | base) to check the state of the card. | If you use mrsas, you need megacli, which is only in ports, and the | port hasn't translated to pkg probably because of license | restrictions. ( _LICENSE_RESTRICTED = delete-package | delete-distfiles), but the license listed is just "megacli". | * We want to deploy a cron job to periodically check the raid status | (we're writing a wrapper, also having it check mfiutil, zpool, etc). | * We do not want to install and manage a whole ports tree on every | machine in our fleet, just to install a raid utlity. | Option A: | Make a local package somehow. | The port just downloads a static binary, there's nothing to build | here, but we want to do this the "right" way. Is there some way to | have pkg deploy a single local package for this that will, for | example, report the right package ownership, without moving every | other package to our poudriere install (we're just using base | packages, we keep poudriere around for testing in case we need to | hot-patch something). | For what it's worth, we use puppet for config management, so pushing | out the static binary is not the worst answer, but it also feels | "dirty". | Option B: | Figure out how to fix the license. I have no idea what this would | involve. | Option C: | Also, apparently MegaCLI is no longer maintained (replaced by | StorCLI), but there's no port for StorCLI, and...there are multiple | raid-card specific versions? Jeez. | Feels even more dirty. | [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl | i-for-freebsd-and-other-operating-systems | Ideas welcome? | -Dan Mahoney Although the path to get to StorCli goes through various cards the latest greatest seem to work on all earlier cards. It works on HBAs and not just RAID cards. At work I did a Linux/FreeBSD POC for FW management and found the FreeBSD version could flash the HBA and drive FW. I've moved to StorCli from MegaCli. I would suggest we drop the MegaCli port and move to StorCli. I have code to make mfiutil into mrsasutil and added the MFI ioctl handler to mrsas. I'm not sure how much value that has. I don't deal with supporting FreeBSD and RAID much anymore. If interested I could send patches. |Since sysutils/megacli: |- has no dependencies |- has nothing to build |- only carries single binary |- updates are not supposed to happen in future | |it may worth to just do `make package` once (manually or with puppet |recipe) on some dedicated system and then deploy it with puppet |directly. poudriere is overkill for this task imho. Doug A.
Re: MegaCLI port is ports-only -- how would you deploy it?
> On Aug 8, 2022, at 15:57, Doug Ambrisko wrote: > > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote: > |03.08.2022, 02:07, "Dan Mahoney" : > | Hey there all, > | At the dayjob we have a fleet of Dell Poweredge servers that can use > | either mptsas or mrsas -- if you use mptsas, you use mptutil (in > | base) to check the state of the card. > | If you use mrsas, you need megacli, which is only in ports, and the > | port hasn't translated to pkg probably because of license > | restrictions. ( _LICENSE_RESTRICTED = delete-package > | delete-distfiles), but the license listed is just "megacli". > | * We want to deploy a cron job to periodically check the raid status > | (we're writing a wrapper, also having it check mfiutil, zpool, etc). > | * We do not want to install and manage a whole ports tree on every > | machine in our fleet, just to install a raid utlity. > | Option A: > | Make a local package somehow. > | The port just downloads a static binary, there's nothing to build > | here, but we want to do this the "right" way. Is there some way to > | have pkg deploy a single local package for this that will, for > | example, report the right package ownership, without moving every > | other package to our poudriere install (we're just using base > | packages, we keep poudriere around for testing in case we need to > | hot-patch something). > | For what it's worth, we use puppet for config management, so pushing > | out the static binary is not the worst answer, but it also feels > | "dirty". > | Option B: > | Figure out how to fix the license. I have no idea what this would > | involve. > | Option C: > | Also, apparently MegaCLI is no longer maintained (replaced by > | StorCLI), but there's no port for StorCLI, and...there are multiple > | raid-card specific versions? Jeez. > | Feels even more dirty. > | [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl > | i-for-freebsd-and-other-operating-systems > | Ideas welcome? > | -Dan Mahoney > > Although the path to get to StorCli goes through various cards the > latest greatest seem to work on all earlier cards. It works on > HBAs and not just RAID cards. At work I did a Linux/FreeBSD > POC for FW management and found the FreeBSD version could flash the HBA > and drive FW. I've moved to StorCli from MegaCli. I would suggest > we drop the MegaCli port and move to StorCli. > > I have code to make mfiutil into mrsasutil and added the MFI ioctl > handler to mrsas. I'm not sure how much value that has. I don't > deal with supporting FreeBSD and RAID much anymore. If interested > I could send patches. This feels like it should be in base, regardless. Just *something* to query the raid status and health, even if it doesn't ring all the bells of StorCLI. Right now, you can do this with the older mfi, but not the newer mrsas, which performs better in some cases, which leaves an admin with a dilemma: better reliability, or better manageability. I also feel like this could be added to a minor release (i.e. a 12.3 --> 12.4 or a 13.0 --> 13.1), but obviously that decision is above me. -Dan
Unmaintained FreeBSD ports which are out of date
Dear port maintainers, The portscout new distfile checker has detected that one or more unmaintained 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. Please consider also adopting this port. If any ports have already been updated, you can safely ignore the entry. An e-mail will not be sent 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 +-+ databases/mysql-connector-odbc | 5.3.13 | 8.0.26 +-+ 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 Reported by:portscout!
Re: MegaCLI port is ports-only -- how would you deploy it?
On Mon, Aug 08, 2022 at 04:10:10PM -0400, Dan Mahoney wrote: | | | > On Aug 8, 2022, at 15:57, Doug Ambrisko wrote: | > | > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote: | > |03.08.2022, 02:07, "Dan Mahoney" : | > | Hey there all, | > | At the dayjob we have a fleet of Dell Poweredge servers that can use | > | either mptsas or mrsas -- if you use mptsas, you use mptutil (in | > | base) to check the state of the card. | > | If you use mrsas, you need megacli, which is only in ports, and the | > | port hasn't translated to pkg probably because of license | > | restrictions. ( _LICENSE_RESTRICTED = delete-package | > | delete-distfiles), but the license listed is just "megacli". | > | * We want to deploy a cron job to periodically check the raid status | > | (we're writing a wrapper, also having it check mfiutil, zpool, etc). | > | * We do not want to install and manage a whole ports tree on every | > | machine in our fleet, just to install a raid utlity. | > | Option A: | > | Make a local package somehow. | > | The port just downloads a static binary, there's nothing to build | > | here, but we want to do this the "right" way. Is there some way to | > | have pkg deploy a single local package for this that will, for | > | example, report the right package ownership, without moving every | > | other package to our poudriere install (we're just using base | > | packages, we keep poudriere around for testing in case we need to | > | hot-patch something). | > | For what it's worth, we use puppet for config management, so pushing | > | out the static binary is not the worst answer, but it also feels | > | "dirty". | > | Option B: | > | Figure out how to fix the license. I have no idea what this would | > | involve. | > | Option C: | > | Also, apparently MegaCLI is no longer maintained (replaced by | > | StorCLI), but there's no port for StorCLI, and...there are multiple | > | raid-card specific versions? Jeez. | > | Feels even more dirty. | > | [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl | > | i-for-freebsd-and-other-operating-systems | > | Ideas welcome? | > | -Dan Mahoney | > | > Although the path to get to StorCli goes through various cards the | > latest greatest seem to work on all earlier cards. It works on | > HBAs and not just RAID cards. At work I did a Linux/FreeBSD | > POC for FW management and found the FreeBSD version could flash the HBA | > and drive FW. I've moved to StorCli from MegaCli. I would suggest | > we drop the MegaCli port and move to StorCli. | > | > I have code to make mfiutil into mrsasutil and added the MFI ioctl | > handler to mrsas. I'm not sure how much value that has. I don't | > deal with supporting FreeBSD and RAID much anymore. If interested | > I could send patches. | | This feels like it should be in base, regardless. Just *something* to | query the raid status and health, even if it doesn't ring all the bells | of StorCLI. | | Right now, you can do this with the older mfi, but not the newer mrsas, | which performs better in some cases, which leaves an admin with a | dilemma: better reliability, or better manageability. | | I also feel like this could be added to a minor release (i.e. a | 12.3 --> 12.4 or a 13.0 --> 13.1), but obviously that decision is above me. This is based of -current. I haven't tested it recently: https://people.freebsd.org/~ambrisko/git.mrsas_support_in_mfiutil.patch Please give it a try. You will need a new kernel built and booted to provide the needed ioctl support. It should be close to committable. Thanks, Doug A.
Re: MegaCLI port is ports-only -- how would you deploy it?
03.08.2022 6:07, Dan Mahoney wrote: > Ideas welcome? Do once on a build system: "make package" to obtain packagename.pkg Do once on every target system: fetch (or scp) the package file then: pkg add /path/to/packagename.pkg It installs the package properly. A package is not obliged to come from a repository.
