08:01:35 <pilonsi> Good morning! I'm about to send the integration request and checking the mail_msg I'm seeing a diff in the ELF runtime attributes
08:02:42 <pilonsi> 17092a17093,17094
08:02:48 <pilonsi> > usr/bin/adb: NEEDED=libc.so.1
08:02:54 <pilonsi> > usr/bin/adb: RPATH=/usr/gcc/10/lib
08:03:00 <pilonsi> 31226,31227d31227
08:03:07 <pilonsi> < usr/lib/isaexec: NEEDED=libc.so.1
08:03:13 <pilonsi> < usr/lib/isaexec: RPATH=/usr/gcc/10/lib
08:04:32 <pilonsi> I imagine this has nothing to do with the change for 15839 but I'm not entirely sure if it's got something to do with my setup, or is caused by other changes I've pulled in
10:21:38 <Agnar> tsoome: ping?
12:33:46 <paulf> +Could not load the Python gdb module from `/usr/local/share/gdb/python'.
13:46:27 <paulf> seem to have gotten past that now
13:46:30 <paulf> +warning: could not convert 'breakme' from the host encoding (ISO-8859-1) to UTF-32.
13:46:31 <paulf> +This normally should not happen, please file a bug report.
13:49:06 <yuripv> is that on omnios?
13:49:46 <paulf> no openindiana hipster trying to get gdbserver working
13:49:50 <yuripv> kk
13:50:11 <yuripv> saw the latter on omnios, but andyf fixed that with guile update
15:16:10 <robertdfrench> I ran into that on omnios
15:16:40 <robertdfrench> yuripv: when was that fixed? In bloody, or is it in r151046 ?
15:18:06 <yuripv> in bloody, some days ago
15:18:18 <yuripv> (at least i'm running bloody)
15:35:51 <robertdfrench> DEECENT!
15:35:57 <robertdfrench> Okay, I'll have to give that a look
16:54:42 <robertdfrench> oh, paulf didn't realize you were in this channel too
16:55:01 <robertdfrench> I cannot reproduce what yuripv said about this being fixed in bloody.
16:55:39 <robertdfrench> andyf: does this issue ring any bells for you? That is, gdb fussing about "could not convert from host encoding to UTF"?
16:58:58 <alanc> for what it's worth, I see the gdb encoding message on Solaris 11.4 as well
17:00:24 <robertdfrench> thanks alanc ! So, have any of y'all opened a gdb bug yet? I have an account on their bug tracker and can make one real quick
17:00:38 <alanc> I haven't
17:00:51 <robertdfrench> paulf: have you?
17:02:11 <robertdfrench> looks like nothing related in the past few days. I am gonna go ahead and file this. Will drop a link here.
17:14:33 <robertdfrench> Rather than opening a new bug report, I just chimed in on https://sourceware.org/bugzilla/show_bug.cgi?id=29315
17:14:58 <robertdfrench> That one already mentions Solaris, and it's still marked as 'NEW'
17:17:02 <sommerfeld> pilonsi: didn't see anyone respond to you.   that's a bit of non-determinism in pkgsend; it sees a file in the filesystem with N links into one "file" and N-1 "hardlink" actions and it sometimes chooses differently.
17:25:20 <paulf> not opened any gdb bugs for that yet, just the problem with socketpair in the configure detection
17:29:48 <sommerfeld> pilonsi: excuse me, not pkgsend, but check_rtime
17:34:04 <alanc> pkgsend also has that problem (though you can use --target to tell it which to pick), it's just not involved in this case
17:41:52 <sommerfeld> (ah, digging further it's usr/src/tools/find_elf/find_elf.c).  it walks each directory in the order returned by readdir() rather than in a canonical order.
17:49:10 <jbk> the original perl script did the same
18:48:11 <jbk> the C version however (had to remember the specifics because it's been a while) does have special knowledge of certain 'well known' hardlinked binaries (usr/bin/alias and usr/lib/isaexec)
18:48:39 <jbk> and tries to produce more 'expected' results when encountering hard links
18:48:51 <jbk> if there's others where it makes sense, it'd be trivial to add
18:55:21 <jbk> could also sort them, but if you add a new link that appears before the current first one, you end up in the same situation
20:45:45 <gitomat> [illumos-gate] 15487 smbios: storing the address of local variable -- Toomas Soome <tsoome⊙mc>
22:52:03 <gitomat> [illumos-gate] 11988 build DHCP client tools with CTF -- Joshua M. Clulow <josh⊙so>