00:30:28 [illumos-gate] 17042 cxgbe leaks tx_dhdl array -- Patrick Mooney 01:04:23 Hello. I am having an issue with gmake on illumos. Here's what's happening; I started a build using gmake on OpenIndiana (GNU Make 4.3), and ran the build side-by-side on Ubuntu (GNU Make 4.3, also). Ubuntu proceeds with the build, while OI returns an error "Badly formed macro assignment". I looked the Makefile and the first error was on a line 01:04:24 showing *VALUE ?= $(VALUE)*. I changed this to *VALUE = $(VALUE)* and it proceeds to the next line with a *?=*. Changing the whole file like this passes and the Makefile runs... I can't find anything that would suggest this discrepancy in behavior online. Has anyone else ran into this issue? 01:08:08 are you sure you're running GNU make and not Solaris make? because that sounds like what Solaris make would do if given a GNU makefile 01:08:41 you don't have $MAKE set anywhere do you? 01:10:01 Yes, illumos make doesn't support ?=, and would print that message if it saw it 01:10:15 Yes, I am using gmake. $MAKE is not set 01:10:20 so somehow it's run our make and not gmake 01:10:48 that often happens if someone wrote a recursively makefile, but called 'make' for the subdirectories, not $(MAKE) 01:11:10 oh yeah, good point 01:11:18 the easiest workaround on openindiana is probably to put /usr/gnu/bin first in your path, while running the make 01:16:01 Thanks alanc richlowe 01:16:11 This appears to be the case. I put /usr/gnu/bin first in the path and there's no more Makefile error 03:22:47 hrm... 03:42:25 it looks like a lot of our section 1 man pages include paths, while most everyone else I've checked does not 03:43:38 aside from instances where it matters (e.g. xpg4/6 versions), do we care? 03:44:09 (e.g. the usual use of mandoc you'll end up without it since it uses the .Nm value from the name section for the rest of the man page 08:53:18 jbk: I think we qualify the path when the program is [a] not in /usr/bin, or [b] there is more than one program (e.g., an xpg4 and a regular variant), or [c] there is a shell built-in and an actual program 08:53:53 so, e.g., there are paths in ls(1), but not in grep(1) any longer since unification 08:55:11 There might be some outliers that get qualified anyway, but I suppose one could argue those could become unqualified, as long as there is only one program and it's in /usr/bin 18:49:33 [illumos-gate] 17062 kernel thinks lwp0 has a usable FPU save area when it doesn't -- Andy Fiddaman 19:33:26 Good evening. Did we recently (between February 2024 and now) change the default brand permissions? My Zone now gets EACCESS to /def/ipf 19:33:33 Good evening. Did we recently (between February 2024 and now) change the default brand permissions? My Zone now gets EACCESS to /dev/ipf 19:33:53 or could that be drift between the zone and host? 19:36:37 I don't remember anything changing there. 19:39:51 ppriv debugging might give more specific information about missing privileges (ppriv -e -D $cmd) 19:40:39 I usually use GZ-managed firewall for my zones these days, but I'm pretty sure you can combine both. 19:47:20 andyf well the GZ is the router for all but the Zones have public IP's 19:47:34 at least some NAT zones do 19:48:40 sommerfeld that just gets me 'Permission denied setting zone: /etc/ipf/ipf.conf' 19:49:59 You can still create a set of GZ-managed ipf rules for a zone, with `ipf -G` - they aren't visible from within the zone so it's good for ones that are less trusted. The zone can define its own set on top of that. Not related to your problem, I don't know what's happening there. 19:52:19 so if I load the rules with -Gzone it would load the into the zone? 19:54:10 They're two separate things, the rules controlled by the GZ and the rules controlled by the zone itself. 19:54:11 "into the zone" isn't really a thing there 19:54:25 Does truss show anything, which system call is returning EPERM? 20:08:09 ioctl(4, _IOWRN('r', 97, 68), 0x004238E0)       Err#13 EACCES 20:08:57 Which is just after open("/dev/ipf", O_RDWR)                        = 4 20:14:03 At least it means you have the device in the zone, just no permissions for some reason. Do you get the same if you try and enable the firewall? - ipf -E 20:42:16 andyf so host is back. ipf -E works but not -F apparently. 20:42:50 buuut since I have an empty firewall anyway I can just leave off the flush 20:49:35 `-F` complaining it can't flush rules from the GZ? 20:49:43 (a complete guess) 20:51:10 well i zlogin to the zone and then run ipf -F 21:29:56 danmcd: my fix for the rsync alloca() issue was a bit more extensive: https://github.com/RsyncProject/rsync/pull/712 (though our official builds didn't hit it because they link against our popt package instead of the bundled copy in rsync) 21:51:30 the rsync problems were all in rsyncd right? 21:51:39 Heh heh, yeah that'll work. 21:51:56 Malicious servers can cause clients to send other things. There were 6 CVes. 21:52:14 Though that problem isn't as bad as the rsyncd side of things were. 21:52:46 Don't forget, unless your distro does something weird, "rsyncd" isn't a binary, you just run "rsync --daemon" or some such. 21:53:01 (It took me hours to get my head wrapped around that this week. :( ) 21:53:03 yeah, I was meaning areas-of-function wise, not specifically 21:55:10 (precisely because it's all rsync under the hood, and hard to describe otherwise, yeah) 22:01:31 3.4.1 is out now btw 22:01:49 3.4.0 broke -H -.- 22:05:29 oh, I use that. 22:05:34 not often, but. 22:07:44 at least it broke it in an obvious way (the exceution fails immediately)