01:57:54 rmustacc: (just in case you have any thoughts on this)... the sff page a2 values have a few dependencies on values from page a0 for interpretation (which causes some challenges with the current libsff api) for SFPs at least.. qsfp has potentially different challenges... 01:59:19 just to mess around a bit with the data (i.e. I'm not convinced this is the way to go)... I just changed things slightly to optionally allow an existing nvlist_t to be passed back into the libsff_parse() so it can get the values from page a0 (if an nvlist was passed in and it contained the resulting keys from parsing page a0) 02:00:44 (additional data for qsfps would require writing to the transceiver if I'm reading things correctly, so that's a whole other deal, questions, etc, so avoiding that for now) 15:28:33 out of curiosity, has anyone tried to build the latest influxdb (the new rust version) on illumos? 15:28:38 (tried recently) 15:29:42 last time I tried, it required a fair amount of uhm.. persuasion, and the resulting binaries were absolutely massive (> 1GB -- the release binaries)... wondering if things have changed/improved any.. 15:35:41 A Influxdb IPS pkg manager package from the OI repositories would be nice. 15:36:08 The mongodb IPS package is outdated and can't be installed. 15:36:41 On OI. 15:39:57 root@openindiana ~ # pkg list -a | grep influx -> Empty. 15:54:36 last time I tried, it was largely dependency issues from what I recall.. 17:48:49 Aedil: Looking forward to your packages :) 18:06:17 Aedil, there are influx-cli-2.3.0 and influxdb-1.8.4nb39 , says pkgin with pkgsrc package manager on SmartOS . You can take a look there for maybe porting to IPS. Maybe upgrade that to latest and port 18:38:40 Maybe I can contribute a IPS package in future. But right now I am not educated enough to do that. 19:06:50 Aedil: https://docs.openindiana.org/dev/userland/ and the pkgmogrify manpage and all things start falling into place :) 19:10:15 alanc did you or somebody from the solaris team at some point add full 64bit symboltables or other work to support large PIC code like rustc? Something like GOT22? 19:55:29 toasterson: Thank you for your information. 20:09:17 toasterson: that question doesn't make sense 20:09:54 the only GOT22 I know of is a SPARC relocation with a marginally larger displacement than usual 20:10:01 which I assume is what you mean because "large pic" 20:10:08 but it's been supported for ever? 20:16:09 richlowe: I think I am still not quite read up on the details exactly. But basically Klaus and I managed to trigger a linker error while cross-compiling to sparc namely (.text+0x70): relocation truncated to fit: R_SPARC_GOT13 against symbol `___Argv' defined in .bss section in /opt/illumos//sysroot/usr/lib/sparcv9/crt1.o using sunstudio compiler made this pass but that seems like a bad idea since after that we trigger alignment issues. 20:18:21 right, that would probably want the got22 relocation from a larger model 20:18:41 ah, but it's the crt, so probably you need to explicitly go do that 20:19:08 How would we do that? :) 20:19:52 probably need to build common-crt.o etc with the large model 20:20:35 does x86 already do that in the makefiles? 20:22:05 i can't recall if i've asked, but would there be interest in adding an option to SMF (really svc.startd) to control the timestamp format used in svc logs (e.g. use ISO timestamp format) ? 20:24:56 toasterson: I don't think x86 needs a larger model 20:25:13 jbk: I always love an ISO format timestamp 20:27:09 richlowe: ah, ok so how does one enable that larger model on SPARC? 20:32:30 certainly not anything I did nor remember hearing about 20:33:15 -mcmodel=large maybe? 20:33:21 I dunno, the GCC manual will 20:33:58 just tried the influx stuff again.. 20:34:15 and yeah, the bespoke way of building C stuff with rust is breaking on omnios 20:34:49 why bespoke can be so bad 20:35:27 tbh, i don't think i've ever seen it work on illumos, but probably don't do enough 20:35:48 (where cargo tries to build C stuff with custom rust code) 20:44:13 Aedil, would be fun maybe upgrading influxdb package on SmartOS and use that later. Besides, you can bootstrap pkgsrc on other illumos distro and happily use pkgsrc packages, too. I used to do that for years. See Standard and then, Standard(upgrade) , https://pkgsrc.smartos.org/install-on-illumos/ 20:49:22 (yeah, now I remember.. some crate is trying to use protobufs, but to get the standard definitions, flags need to be passed to protoc, but since they use build.rs (basically a rust program that's compiled and then run to build things, it has no provision for passing that down (short of modifying the program) 20:49:39 (vs being able to override/supplement things with make) 20:53:34 jbk: most of it is using standardized crates now still bespoke to the language but manageable. usually there are variables to make it use prebuilt versions and set okg_config paths etc. 20:56:28 nikolam: Thank you. I will have a look at that HOWTO. 20:58:33 richlowe: does that -mcmodel=large even work on a file like mach-crt1.S ? would that not need manual adjustment? 21:02:05 no, but it's probably crt-common.c that needs it 21:07:01 yeah, i'm not seeing anythig.. though i suppose a question is should protoc implicitly be searching where the 'built-in/default' definitions are 21:11:30 e.g. like how gcc implicitly has -I/usr/include unless told otherwise 22:27:41 richlowe: thanks found where I need to put C_BIGPICFLAGS :) 22:29:10 jbk: protoc has it's own way of finding things. Last time I tried protoc it just kinda worked on OpenIndiana. Whats the error that you get? 22:40:55 so digging further 22:41:03 where is protoc installed on openindiana? 22:41:11 /usr/bin ? 22:41:27 actually that might not matter... 22:41:34 https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/compiler/command_line_interface.cc#L217-L248 22:41:39 that's the problem 22:42:05 it _is_ in fact supposed to look at (to borrow our linker's nomenclature) $ORIGIN/../include 22:42:12 by default for .proto files 22:42:28 and that's how it's adding that path 22:42:36 so on illumos, we don't get that added 22:42:50 of course, if you explicitly add -I/usr/include or whatever 22:42:52 it's fine 22:43:06 assuming you can easily do that 22:43:35 jbk: it's in /usr/bin/protoc 22:44:01 what path do you need to add for protoc files? 22:44:06 so teh fix is to make that work 22:45:49 we have proto files under usr/include/google/protobuf/wrappers.proto for example 22:48:34 yes, and on omni, that's all under /opt/ooce 22:49:06 and because that code I pasted fails on illumos, it won't find those unless you explictly tell it to 22:49:16 (which isn't always easy) 22:49:31 I mean, interacting with google can be unpleasant, but it seems like fixing protoc is the way? 22:49:32 because it's several levels deep in some dependency of a build 22:49:36 yeah 22:50:40 having waded through the C++ to figure out it was supposed to do that (not really documented) 22:50:59 i'm going to put up some PRs and patches 22:52:34 Yeah there is only really -I that you can append to the protoc call as argument 22:53:00 is it the tonic or prost crates? 22:53:52 jbk: I feel like Oracle added some timestamp improvements to their SMF already; might be worth looking to see if it's worth being compatible 22:59:07 jbk: if it's either tonic or prost than you can set export PROTOC_INCLUDE=/opt/ooce/include just for this case before cargo build 23:00:56 jclulow: I see $SMF_SVCS_DATE_FMT (for svcs) but nothing else (though if anyone is aware of anything else, yeah -- no need to be different if there's not a good reason)