08:53:16 <DangrOnTheRangr> selsta: just double-checking that you had seen I had squashed the commits on 7823
12:09:09 <selsta> DangrOnTheRangr: approved it
12:11:53 <Space[m]> mj-xmr: I compiled monero on Master
12:12:08 <mj-xmr[m]> Great. Thanks. Were there any changes needed?
12:13:41 <selsta> anything remaining that isn't merged yet that should be included in the next release?
12:13:45 <Space[m]> mj-xmr[m]: All dependencies remain the same, only instead of release - master
12:14:26 <Space[m]> In both cases, I used the patch for boost 1.76
12:15:11 <mj-xmr[m]> selsta: IDK, but maybe these 3 UB protections?
12:15:11 <mj-xmr[m]> (searchable by "UB"
12:15:39 <Space[m]> Space[m]: but used boost 1.77
12:16:01 <mj-xmr[m]> 7870 7868 7861 and 7829
12:16:50 <mj-xmr[m]> Space: I'm not sure now what happened. Did everything (release & master) work without changes with boost 1.76 but not with 1.77?
12:19:59 <Space[m]> mj-xmr[m]: in both cases used boost 1.76... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e2b34298c270b4111c01e0a0b51fc37d3101143d)
12:20:16 <Space[m]> > <@mj-xmr:matrix.org> Space: I'm not sure now what happened. Did everything (release & master) work without changes with boost 1.76 but not with 1.77?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/4cc9b4a59f71e8ad5056efabc8418111df496556)
12:20:58 <mj-xmr[m]> ok. Now it's clear for me. Thanks.
12:21:15 <mj-xmr[m]> I will build boost 1.77 rn and try to reproduce.
12:21:30 <mj-xmr[m]> If I can't, I will get back to you.
12:23:17 <Space[m]> mj-xmr[m]:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/59662ced9ae3326ad5a530e6129fb689d008cf49)
12:23:34 <mj-xmr[m]> Thanks. This can be useful.
12:23:37 <Space[m]> > <@mj-xmr:matrix.org> If I can't, I will get back to you.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ec57f8bcce45c814b9ceb054e681223649a5d9a8)
12:23:54 <Space[m]> > <@bigmenpixel:matrix.org> note: boost is compiled like this... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/7b6742bf9ff267fcfba0a7883d0d567d33c8cdbc)
12:29:52 <selsta> mj-xmr[m]: someone has to review them, I'm not really familiar with it
12:32:36 <mj-xmr[m]> OK, then let's pass them for now.
13:03:45 <mj-xmr[m]> Space: I can reproduce the Release with Boost 1.77
13:04:12 <mj-xmr[m]> I will try with 1.76 as well just to be sure. But it seems to me, that Boost is actively cutting on the size of their headers. Which is good.
13:09:32 <Space[m]> <mj-xmr[m]> "Space: I can reproduce the Relea" <- without patch?
13:11:15 <mj-xmr[m]> without patch
13:11:49 <mj-xmr[m]> But the patch seems only slightly related to me, looking at the error message.
13:12:02 <Space[m]> mj-xmr[m]: Hmm ... even archlinux uses a patch in its package
13:12:07 <mj-xmr[m]> It may fix this but only indirectly.
13:12:23 <mj-xmr[m]> And this is not the way we want to have it in long term.
13:12:52 <mj-xmr[m]> Since such "solutions" will cease to work when boost cuts yet another header (as they should)
13:13:48 <mj-xmr[m]> I'm about to create the "proper" patch for this particular situation and we'll decide how to proceed.
13:14:59 <Space[m]> mj-xmr[m]: ok
13:16:09 <Space[m]> Let the flatpak package monero-gui 0.17.2.2 lie down as a binary for now, without building from sources
13:23:33 <selsta> mj-xmr[m]: can you post the error message with Boost 1.77?
13:24:56 <mj-xmr[m]> selsta: TL;DR: https://paste.debian.net/1209409/
13:25:26 <mj-xmr[m]> `/run/build/monero/src/common/i18n.cpp:74:8: error: ‘transform’ is not a member of ‘std’`
13:25:47 <selsta> that's boost?
13:26:08 <mj-xmr[m]> No. It's fishy.
13:26:19 <mj-xmr[m]> It appears that your patch fixed it indirectly.
13:26:42 <mj-xmr[m]> but since boost 1.77, that included header dropped <algorithm> from its included headers.
13:26:54 <selsta> ok I see
13:26:59 <mj-xmr[m]> and thus it was missing down there in i18n.cpp
13:27:20 <selsta> otherwise no compilation issues?
13:27:26 <Space[m]> What version of boost is the github release compiled with?
13:27:37 <selsta> 1.64 or so
13:27:51 <mj-xmr[m]> selsta: just finishing compilation
13:29:59 <selsta> do you want to PR it?
13:30:07 <mj-xmr[m]> selsta: all green. Shall I PR against 
13:30:19 <mj-xmr[m]> took it from my brain
13:30:28 <selsta> both master and release
13:31:01 <mj-xmr[m]> Master already has the header included.
13:36:33 <mj-xmr[m]> 7902
13:37:37 <mj-xmr[m]> bbl
13:40:12 <selsta> mj-xmr[m]: can you change the position of the include? unless it was intentional
13:45:47 <mj-xmr[m]> selsta: it was intentional. Basic headers always go below own headers.
13:46:47 <mj-xmr[m]> https://stackoverflow.com/a/14243688
13:47:10 <selsta> but we don't do it like that currently
13:47:44 <selsta> hmm ok, whatever
13:47:50 <mj-xmr[m]> Somebody has to start :)
14:25:35 <hyc> that is nonsense
14:26:12 <hyc> most local headers depend on standard headers. e.g. NULL is defined in <stdio.h>
14:26:23 <hyc> whoever wrote that doesn't know wtf they're talking about
14:26:55 <hyc> basic headers should always come first. local headers last.
14:31:03 <hyc> complex systems are built from the ground up. always define the basics first and then build on top of them. not the other way around.
14:31:18 <hyc> stackoverflow idiocy...
14:33:50 <UkoeHB> Can you give a practical reason to include basic first? I think including local first makes a lot of sense for catching missing header dependencies.
14:34:38 <hyc> again, it's just common sense. I can't use a local header that uses FILE* without including <stdio.h. first.
14:34:49 <UkoeHB> Common sense? Lmao that is not a practical reason.
14:35:04 <hyc> you have to include the lowest level deinitions before you can build higher level abstractions on top of them
14:35:32 <UkoeHB> Yes, headers should include their own lowest level definitions.
14:35:40 <hyc> no, that's fucking stupid.
14:35:54 <UkoeHB> That just an opinion, give me a practical reason.
14:35:59 <hyc> that means every high level local header file includes the entire world that it depends on
14:36:28 <hyc> even with annotations to only include_once it still wastes time opening and ignoring all of the header files redundantly
14:36:39 <hyc> include what you need before you need it, and only do it once.
14:37:49 <hyc> I swear, it's as if every C++ practice is designed to waste developer and user time
14:38:16 <UkoeHB> Isn't tracking down all the dependencies of all the headers you include, wasting time?
14:38:25 <hyc> you only do it once.
14:38:32 <hyc> and from then on compiles are fast.
14:38:57 <hyc> edit/compile/run cycle time matters.
14:39:16 <mj-xmr[m]> <UkoeHB> "Can you give a practical..." <- exactly
14:40:09 <mj-xmr[m]> UkoeHB: Or waiting for compilation to finish.
14:40:12 <hyc> you haven't given a valid reason to change to the opposite order.
14:40:26 <hyc> in absence of a reason to change, don't change.
14:40:27 <mj-xmr[m]> He did.
14:40:54 <mj-xmr[m]> It catches the missing dependencies.
14:40:59 <hyc> so you're going to submit PRs now to invert the order of all includes in all source files?
14:41:08 <mj-xmr[m]> before you distribute your library.
14:41:19 <hyc> fixing what ain't broke...
14:41:29 <mj-xmr[m]> They are already inverted.
14:41:34 <mj-xmr[m]> in the wrong way
14:41:36 <UkoeHB> lol
14:41:41 <hyc> that's just BS
14:42:30 <hyc> you want to define the roof of the house before the walls, floors, or foundation
14:45:11 <hyc> restating the example: you can't use types from <stdint> in your own definitions before you include <stdint.h>
14:45:26 <hyc> the low level headers must always come first
14:45:39 <UkoeHB> Bludgeoning us with insults and empty abstractions is rude and unhelpful. Please keep it technical.
14:45:58 <hyc> \I've already given you technical examples which you ignore
14:46:23 <hyc> ........................
14:46:26 <UkoeHB> Did I ignore them? Now you are mind-reading also, which is equally as rude and unhelpful.
14:46:30 <hyc> ^ cat on kbd
14:48:19 <hyc> yes, you've ignored them. you certainly have not acknowledged them before continuing your argument. *That* is rude and unhelpful.
14:48:30 <UkoeHB> I continued my argument?
14:48:32 <UkoeHB> Where?
14:48:45 <UkoeHB> Here I am thinking about what you said while you spout off.
14:48:50 <UkoeHB> ffs
14:55:28 <BusyBoredom[m]> I like to use the google style guide to end these disputes. Here's their entry for include order: https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes
14:55:38 <moneromoooo> ...
14:56:26 <moneromoooo> using a monero block hash as random seed would seem fairer
14:56:56 <moneromoooo> (As long as you're going to solve disagreements with an arbitrary choice)
15:00:18 <BusyBoredom[m]> Alright, just figured I'd share what worked on my projects. 
15:01:25 <hyc> note the Exception on that section
15:01:56 <hyc> if you blindly throw headers in in arbitrary order you'll usually get a broken result
15:02:20 <hyc> because conditionals that depend on other definitions are a frequent occurrence
15:12:37 <hyc> the one rule that always works, with no exceptions, is always go from lowest level first to highest level last.
15:22:26 <selsta> .merge+ 7902
15:22:26 <xmr-pr> Added
18:27:59 <Space[m]> is this fixed in master?
18:27:59 <Space[m]> https://bin.snopyta.org/?5853cb5ae93281b6#Dvci2f6ZVbjXVxc9bARJxzuT2Lo3SMv3r6AyYTxc26jV
18:30:45 <selsta> it's not a known problem
19:27:59 <wfaressuissia> "is this fixed in master?" how to reproduce it ?
19:29:24 <wfaressuissia> master + arbitrary build environment == undefined behavior
19:29:39 <wfaressuissia> * any branch + ...
19:42:16 <selsta> .merges
19:42:16 -xmr-pr- 7828 7902
19:42:53 <selsta> luigi1111w: once you merge ^ you can tag v0.17.2.3
19:48:42 <selsta> .merge+ 7888
19:48:43 <xmr-pr> Added
19:55:52 <utxobr[m]> <selsta> "luigi1111w: once you merge ^ you..." <- aka "folks, get ready for gitian sigs party"?
19:56:05 <selsta> tomorrow most likely, yes :P
19:56:19 <utxobr[m]> sweeet
19:57:03 <Mochi101> Is there an IRC channel specific to the COMIT tools?
19:57:33 <selsta> afaik they are matrix only but you can ask in #monero-swap maybe
19:58:42 <Mochi101> ok
20:28:31 <sethsimmons> <Mochi101> "Is there an IRC channel specific..." <- Matrix is #comit-monero:matrix.org, not sure if bridges.
20:29:14 <Mochi101> thanks sethsimmons, doesn't bridge though...
20:30:12 <Mochi101> I set up the ASB... had some input on it... was doing the CLI as well and had some difficulties
20:39:35 <sethsimmons> Let's chat in #monero:monero.social 
20:40:27 <sethsimmons> Nvm don't see you in there.
20:40:27 <sethsimmons> Feel free to DM and I'll try to answer Qs, assuming you've read my guide and the official docs.
20:40:39 <sethsimmons> Off topic for this channel, though.
22:17:30 <luigi1111w> K