i can totally grok people enjoying the more integrated nature of zfs, but i absolutely adore the more modular approach of the geom stuff and have come to appreciate it more and more over time – and there's probably still lots of cool stuff in there i don't know about – yet. >:3

oh yeah, what i actually wanted to say; rwp, not sure if you're the kinda person who likes closure, but either the amdgpu memleak fix or the upgrade to RC1 seems to have fixed my weird "gpu goes awol after screenblank" problem. :)

(and for some reason "xset -dpms" wasn't a working workaround, didn't figure that one out, tho :P)

Hi community, Is it possible to disable the 'CC', 'CXX' and 'CPP' options for a specific port (ex: firefox) in the make.conf?

GeoBarRod: disable how exactly?

GeoBarRod: you have those set in make.conf and you want to avoid overriding the port, or they're set in the port and you want to override that in make.conf?

So, I asked this last night but I don't think it went anywhere. I'm having issues with Linuxulator where I can run Linux binaries just fine if I'm chrooted into the Linuxulator but, even if I "brandelf -t Linux *linux-bin*", I keep getting this:ELF interpreter /lib64/ld-linux-x86-64.so.2 not found, error 2. And the file in question is there, which is a symlink to

/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2. Could it be the symlink that's bad since on FreeBSD it shows the symlink pointing towards /lib under FreeBSD?

@RhodiumToad I have configured 'CC=clang', 'CXX=clang' and 'CPP=clang' on my make.conf but only firefox don't compile fine.

BillyJoeBob: hm. try changing it to a relative rather than an absolute symlink

GeoBarRod: why did you do that?

I'm assuming it's pointing to /lib under the chroot but FreeBSD is just saying /lib. I'll have to see what you mean. Should I create the symlink in FreeBSD or Linuxulator?

BillyJoeBob: in freebsd is fine

@RhodiumToad I have configured 'CC=clang', 'CXX=clang++' and 'CPP=clang-cpp' on my make.conf but only firefox don't compile fine. Sorry.

GeoBarRod: why did you do that?

GeoBarRod: i.e. why did you put those in make.conf

Hmm...I tried searching for "relative" in the ln manpage with no results found.

@RhodiumToad I want compile all port with Clang.

Is relative the same as a hard link?

for some ports that simply doesn't work, but otherwise it's the default anyway

BillyJoeBob: no, it's a symlink where the destination doesn't start with /

Aaaaah. So I would want *.so.2 -> ../lib/blahblahblah

yes

@RhodiumToad Except Firefox, all the ports for my desktop environment compile fine. That's why I wanted to exclude those variables specifically for the Firefox port.

you shouldn't be defining them at all

what architecture are you compiling on?

@RhodiumToad amd64

port builds on amd64 will always use clang unless you defined FAVORITE_COMPILER=gcc or the port explicitly says it needs gcc, in which case I'm pretty sure the port will override make.conf anyway

@RhodiumToad Oh, that is great! I didn't know that the default compiler for ports was Clang unless the port specified otherwise.

RhodiumToad: Holy shit! That worked!!!

you'll want to go through the whole compat/ tree and make sure any absolute symlinks are converted to relative, then

hehe, Is there a simple way to automate the process of finding absolute links? I think I can convert them by hand.

GeoBarRod: what's supposed to happen is that the port declares what level of language support it needs via USES=compiler:blah and then the framework uses clang if that's good enough, otherwise uses a ports clang or gcc depending

BillyJoeBob: the -lname option of find looks like it might help

Hmm...so something like find /compat/ubuntu/ -lname *.so?

find /compat/ubuntu/ -type l -lname '/*' -ls

GeoBarRod: if you know of any cases where the ports framework is using gcc or a ports llvm unnecessarily, then that might be a bug

GeoBarRod: but regardless, specifying CC etc. in make.conf isn't something you're expected to do (see man make.conf for things that you might do)

@RhodiumToad So, this option 'OPTIONS_UNSET_FORCE= GCC' does not override the one in the port. Correct?

that means that _if_ the port has an option named GCC, it will be turned off

(do any ports have that as an option?)

@RhodiumToad So force will compile with Clang?

no

RhodiumToad: Yeah, I would have never figured that out.

Thanks

port options are the things you configure in the options dialog, they're not arbitrary makefile variables

there's like three ports in the whole tree that have a "GCC" option

@RhodiumToad Please tell me what ports?

devel/kBuild, lang/gambit-c, net-p2p/cpuminer are the only ones I found with a simple grep

@RhodiumToad How you see that so fast?

find and grep are my friends

@RhodiumToad :D

@RhodiumToad Please share the command line chain

find [a-z]* -name Makefile -print0 | xargs -0 egrep -e 'OPTIONS_DEFINE.*GCC' # this won't catch cases where OPTIONS_DEFINE is split over lines or where GCC is in an options group

(assumes you're in /usr/ports to run the command)

@RhodiumToad :-O great! that is a Haiku!

also won't catch cases where there's a Makefile.options or whatever

but those are relatively rare

the point is that having it as an option isn't common

@RhodiumToad Thanks very much for share!!!

more commonly, you'll see a port has something like USES= compiler:gcc-c++11-lib which means it wants a gcc version that handles the c++11 standard with library

if it doesn't specifically need gcc, it should have USES= compiler:c++11-lib and then clang will be used as long as it supports the required language standard and library

you can check what compiler will be used in a couple of ways

@RhodiumToad Yes, I see that, so whith a time all ports can build with Clang

@RhodiumToad <<<you can check what compiler will be used in a couple of ways>>> How?

make -C dir/port -V CHOSEN_COMPILER_TYPE # if the port has a USES=compiler, that'll show the chosen compiler

if it's blank, it'll be using the default

make -C dir/port -V CC ## that will show the chosen value of CC

@RhodiumToad Great, Thanks!!!

in general, you can use make ... -V SOMEVAR to display the value of any makefile variable at the point where all makefiles have been read

Ok, well is late for me here. Thanks again and have nice day!!!

Uh, dang. Is there a way to automate the fixing symlinks to be relative? There's a lot lolo

d

t

Oh, sorry. I was wondering why I couldn't see anything. Helps if irssi is scrolled to the bottom.

CCFL_Man, I should put a caller-id modem on my VOIP POTS line to see if they provide caller-id just out of curiosity. I have no idea if they do or don't.

phryk, Thanks for the closure! I would bet it was the upgrade that fixed the problem. Because it just seems like a bug of some sort. Glad you got it working for you!

I have this weird observation about firefox-118.0.2,2 installed from binary ports.

It opens port 80 and 443 in what look like a lot of probes to a lot of what look like Internet routers.

Then the TCP streams are CLOSED. But the TCP connections hang around in the CLOSED state for a while. bsd.to/h562/raw

Title: h562

They are continuously created the entire time firefox is running and close immediately if I kill firefox. This does not happen on, for example, a Debian system.

Feels like something is not right about the FreeBSD port of Firefox, and it feels like Firefox is doing something obnoxious.

I should have included that one can see those with "netstat -na | grep -e CLOSE -e FIN" while firefox is running.

Hi

I've a trouble with vlan and "arp -i vlan0 -a" reports this:

metafce_mtd (10.100.0.4) at (incomplete) on vlan0 expired [vlan]

? (10.100.0.250) at c8:60:00:8d:bb:e7 on vlan0 permanent [vlan]

I had it running on FreeBSD 13.0 but since the upgrade to 13.2 it doens't work anymore.

I'm sure that it's my fault in config

Title: magnet_web paste from Someone at 217.168.150.38...

Please, have you hint to fix?

Title: magnet_web paste from Someone at 217.168.150.38...

ferz: my rc.conf looks a little different

vlans_em0="4000"

ifconfig_em0_4000=" "

latest firefox blows up on start, leaving this behind in the console

[Parent 43394, Main Thread] WARNING: g_signal_emit_by_name: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed: 'glib warning', file

I guess this should be reported upstream too

hi all

antranigv: you got mail - =D

drobban I do?

nah. sent you a silly pull-request to jailer

antranigv: so sorry if I got your hopes up :-P

drobban nice! illuria/jailer #15

Title: added man.8 for jailer-console by drobban · Pull Request #15 · illuria/jailer · GitHub

drobban Merging it now :))

antranigv: =)

i'm trying to go from "A foo\0B bar\0A baz\0" -> "foo\0bar\0baz\0" using the BSD utilities (i.e. without GNU coreutils), but the FreeBSD cut, sed, and awk don't seem to allow using a null separator; any ideas?

you just want the second field of each? what if there are newlines or other crud in the values?

(the best way to split on \0 is probably to use xargs -0 ...)

IRS or RS doesn't seem to do anything with \0

or i'm doing it wrong

RhodiumToad: second field, and I always know the first field is one byte

so you just want to strip off two bytes from the front?

yeah

and preserve the rest, including any possible newlines or special chars?

yep

a \0 in an argument will end the string, as it is used internally in the arguments to main as string terminator.

this is part of the exec*() system call

a raw \0 would, but a literal '\0' string would not -- if the tool itself accepted backslash escapes

your program will probably won't receive the arguments past the first \0

like e.g. perl -pe 's/\0\S+ //g' if you're fine with artistic license

printf 'A foo\0B bar\0A baz\0' | xargs -0 awk 'BEGIN { for(i = 1; i < ARGC; ++i) printf "%s%c", substr(ARGV[i],3), 0; }'

how do you detect a string's end if null characters can be part of it.

RhodiumToad: ooh nice

output piped through hd is: 00000000 66 6f 6f 00 62 61 72 00 62 61 7a 00 |foo.bar.baz.|

by not making them part of the string

beastie: the \0 is the "line" terminator, not part of the string to keep

by using a sane reperesentation of (size, pointer) instead

e.g. '\0' is a two-character string containing a \ and a 0, it's not a problem

the line terminator is normally \n, but that is a convenion... a by far weaker thing of what is \0 for the C standard library.

using \n as a line terminator causes no end of issues with filenames that might contain \n (maliciously or otherwise)

which is why xargs -0 exists at all

as such.. .that's correct, but then you need to escape the backslash, which is special for the shell... and xargs -0 treats with real null characters, not line delimiters.

find ... -print0 | xargs -0 somecommand...

the backslash is not special when it's inside a single-quoted string

RhodiumToad: okay, sweet, looks like that works perfectly; thanks!

it's preserved even inside a double-quoted string, really

yeah... in that case find outputs \0 characters instead of \n new lines, if you print that to stdout you will see all files one after the other with no separator (as \0 prints nothing on a terminal)

for correctness the awk program should probably have an exit 0; at the end

i.e. awk 'BEGIN { print ARGC; for(i = 1; i < ARGC; ++i) printf "%s%c", substr(ARGV[i],3), 0; exit 0; }'

(this is to make sure that awk never gets as far as reading from stdin, which can mess things up)

dch: well now pkg upgrade wants to remove firefox and thunderbird ...

babz: yep, went down that path

That'll teach me to review the list of changes before pressing 'y'...

Have any drm-515-kmod users that upgraded to 5.15.118 been noticing much higher frequency of crashes on their systems?

yet another crash. I give up (and should get a bouncer).

@kenrap I upgrade and my laptop chash and reboot; after reboot until now all fine.

GeoBarRod: the crashing seems to happen at random, like a heisenbug at the kernel level.

you may end up crashing again at some point

@kenrap Well, my uptime 2h 58m, all fine.

I'll give my machine a good dusting and see if what will help, brb.

@kenrap Good Luck!

Reading the above about firefox... I did pkg upgrade today and it is happy with my installed firefox-118.0.2,2 no problem. (shrug)

@rwp The firefox port version is 119.0 ;)

GeoBarRod, I expect ports to always lead binary packages. Someone must blaze the trail. But the above said "now pkg upgrade wants to remove firefox and thunderbird" so that should be binary packages.

Which I thought was strange. As I am on the boring production stable 13.2-RELEASE-p4 and pkg did not want to remove firefox for me today.

And yet there were two different people above who commented on it wanting to remove their firefox.

@rwp That's weird behavior.

Agreed! Often a negative report is not really useful but I thought I would say, didn't happen here, just the same. Weird stuff happening!

port version leads the package version not least because it takes days to build

@rwp Better than an explanation is a photo of the supposed problem.

Better than a photo would be a text copy of the problem.

Meanwhile... I am running pkg from Quarterly. Because I am boring. The way I like it. If someone were running pkg from latest then I would not see the problem then.

@rwp That is a ASCII photo :D

is there a way to tell pkg do not ever remove this package, regardless of whether it's gone upstream?

pkg lock?

meena, pkg lock package

but that also prevents it from upgrading

@meena Please paste your 'pkg upgrade -n' stdout

I would suppose one could create a custom package which depended upon the package you want to keep and then lock the custom package. That seems like it would effectively prevent the dependent package from being removed.

rwp: it was on latest

Latest! Thanks. That brings closure. What was a mystery is now explained.

quarterly still has 118.0.2,2

GeoBarRod: i'm in bed, and will do no such thing

GeoBarRod: how would that even help anyone?

@nimaje It would help by visualizing the problem.

Postulating that the problem might be one would normally want firefox to upgrade normally. But if something wants to remove it then prevent that removal action. For one example.

So... Seems like one could create a custom new package which depends upon firefox of any version. Then lock it. That would create an obstacle to removing firefox but would allow it to upgrade normally.

I think. I know nothing. Obviously I haven't actually done such a thing myself. So who knows?

(while upgrading from 14:amd64/quarterly to latest)

GeoBarRod: no, the output of pkg at any time has noting to do with *how* to convince pkg to never remove a pkg while still allowing to update it

Title: hastebin

shouldn't that say why pkg wants to remove firefox and thunderbird?

@nimaje for that 'pkg lock -y problematic-package'

I think it likely that the dependencies ffmpeg, vlc, dav1d, upgraded removing the dependency forcing firefox out. Probably they built okay first and firefox is still building.

I think probably firefox will finish building against the current dependencies and then it can be installed. The joys of living on latest! :-)

What does freshports say?

bah.

Or rather baaaa...

As long as we are talking about firefox... I see this strange oddity with firefox. bsd.to/h562/raw

Title: h562

Whenever firefox is running there is a continuous large amount of connections in the CLOSED state until eventually they time out. But new ones are always arriving.

GeoBarRod: as others have already written that prevents updating it and there was already the idea of creating a empty package with just a dependency on the package to keep and locking that, which should proably work, so meenas problem is (probably) solved

"netstat -na |grep -e CLOSED -e FIN | wc -l" says I have 103 in the closed state all from firefox right now.

If I kill firefox then all of those are shutdown immediately. If I start firefox again more quickly appear.

las build failed

And this does not happen on my Debian system with basically the same version of firefox.

s/las/last/

I am thinking that maybe something trying to detect Captured Portal networks is doing something it should not be doing there. But no actual idea.

@babz Run 'pkg lock -y dav1d', after run 'pkg upgrade -n'

connections in CLOSED state don't time out.

rwp: when firefox is still building then the pkg repo doesn't get created, but what could be is that firefox failed to build but would need to be build against a new version of a dependency, so pkg deinstalls the non-compatible old version but doesn't have a new version to install, look in pkg-fallout if firefox failed

connections in CLOSED state either haven't been opened yet, or have closed as far as the protocol is concerned but the userland hasn't closed the socket.

It does seem odd. I hadn't thought about them not actually having been opened yet. I was thinking: en.wikipedia.org/wiki/Transmission_…_Protocol#/media/File:TCP_CLOSE.svg

Title: Transmission Control Protocol - Wikipedia

But things do actually start out in the closed state so maybe that is what firefox is doing.

Does anyone else with firefox running see a lot of these to ports 80 http & 443 https? netstat -na | grep CLOSED

it's more likely that they're old connections not yet closed by userland

it's worth looking for what process has what connection still open.

If I kill firefox then those are all gone immediately.

use lsof or fstat

RhodiumToad, lsof -i | grep firefox: bsd.to/Z1sv/raw

Title: Z1sv

don't grep for firefox, grep for specific connections that are in CLOSED state