[16:24] <arraybolt3[m]> Alright this is going to be a very annoying question possibly, but important. I believe I understand why symbols files exists for libraries, but we also know that Debian is encouraging them to be dropped for C++ libraries and that Andrew is on-board with this idea while we are not. But... why are we not? What possible breakage or disadvantages do we face by dropping the symbols files? I ask because I see that symbols files have
[16:24] <arraybolt3[m]> been dropped in Debian LXQt in more than one spot.
[16:27] <tsimonq2> The reason symbols files exist in the first place is because of ABI compatibility, as in, "the public API should not break unless the developers are prepared for it." There are several occasions in which I've intentionally broken ABI to include a feature, and it is extremely easy to track what is actually available in the library, assuming you have c++filt available 
[16:28] <tsimonq2> I get the impression that symbols files are difficult for them. I couldn't care less what a fully-qualified Debian Developer considers to be "too difficult" when they've been through the grilling process, which includes symbols questions. In my personal opinion, it's an indication of lack of preparation 
[16:30] <tsimonq2> Symbols files come easy to me because I've used them for long enough. They're useful for library packages with many reverse dependencies, and it would be useful to allow other packages to depend on libfm-qt. I forget which precise component handles it, but there's some sort of verification there. I haven't read the debian-devel thread so my opinion isn't as qualified as it should be
[16:30] <tsimonq2> That being said, "growing up" packaging, it was considered to be a terrible practice to just drop symbols files because you don't know to maintain them 
[16:31] <tsimonq2> Which is exactly why I said I was going to "pull a Simon" as in, write them a good five page essay :P
[16:31] <arraybolt3[m]> tsimonq2: The problem is it's not just libfm-qt. Andrew (or at least the people in charge of Debian LXQt) are gutting them out of everything as far as I can tell. libqtxdg is also affected.
[16:31] <arraybolt3[m]> tsimonq2: Ah, I get it.
[16:31] <tsimonq2> Again, probably from the perspective of "oh thank God, we can drop these stupid symbols files now"
[16:32] <tsimonq2> Weak mindset :P
[16:32] <tsimonq2> (In my PERSONAL opinion, to be clear)
[16:32] <arraybolt3[m]> That makes sense.
[16:33] <arraybolt3[m]> But it also means that, lest Andrew end up more upset with me than he already is, I probably should just leave anything with symbols files involved alone.
[16:33] <arraybolt3[m]> Until we have a consensus as to what we're doing (Ubuntu delta or not).
[16:34] <tsimonq2> I'm absolutely +1 on maintaining an Ubuntu delta for symbols and would maintain that position unless there's an actual disadvantage besides developer time 
[16:34] <arraybolt3[m]> Meh, we have developer time.
[16:34] <arraybolt3[m]> One last question...
[16:34] <arraybolt3[m]> If I use a PPA to build something in Launchpad, and it spits out symbols changes at me, are those guaranteed to be compatible with Debian, or do I need to be using Debian itself to make sure the symbols are for sure correct?
[16:35] <arraybolt3[m]> (If the latter, then we do have one very serious disadvantage, namely that symbols can only properly be handled by someone with porterboxes, which I don't have.)
[16:35] <tsimonq2> There's no surefire "always right" answer for that. You have to determine whether the symbols being generated are automatic compiler additions are not. Basic familiarity with C++ helps 
[16:36] <arraybolt3[m]> :-/
[16:36] <arraybolt3[m]> I have some level of familiarity with C++ but still don't know how I would do that.
[16:36] <arraybolt3[m]> (Like I can work on bugs in KDE, but I have no idea what "lvalue" or "rvalue" means.)
[16:36] <tsimonq2> That comes with time heh :)
[16:37] <arraybolt3[m]> tsimonq2: Well how about this. What do "automatic compiler additions" look like? And why would they be different between Ubuntu and Debian?
[16:38] <tsimonq2> I would have to be at my computer to give examples :)
[16:38] <arraybolt3[m]> (I assume they might be different in the event Ubuntu and Debian had different versions of gcc installed right? Also, no problem, I can work on other stuff in the mean time.)
[16:38] <tsimonq2> Yep, you basically hit the nail on the head :)
[16:38] <tsimonq2> GCC is a big factor 
[16:38] <tsimonq2> Same with underlying Qt libraries, too
[16:39] <arraybolt3[m]> Ugh, I didn't think about that.
[16:39] <arraybolt3[m]> So really the only surefire way to know that everything's right is to build on both Debian and Ubuntu I'm guessing.
[16:40] <arraybolt3[m]> I guess I do have a desktop just sitting here, so it's not beyond my ability to build for all of the architectures Debian supports.
[16:40] <tsimonq2> Yeah, but there's a PPA-like service for Debian iirc... debomatic??
[16:40] <arraybolt3[m]> That looks like software you install, not a service.
[16:41] <tsimonq2> Hmm...
[16:42] <arraybolt3[m]> So if I had an s390x box, a RISC-V SBC, etc., that would be handy, but all I have is a slew of i386 and x86_64 hardware, along with a single RPi4 Model B.
[16:42] <tsimonq2> At the end of the day... this is exactly what Debian Experimental is for ;P
[16:42] <arraybolt3[m]> That's a good point.
[16:42] <tsimonq2> (And more)
[16:43] <arraybolt3[m]> Also the debian page on porterboxes says I can request guest account access.
[16:44] <arraybolt3[m]> Eh but that looks pretty strict and they specifically say that requests for "all architectures" aren't OK.
[16:44] <tsimonq2> That's correct. Given that they don't give you root on those boxes, blind sponsorship from me :)
[16:45] <tsimonq2> Okay, so when we discover a problematic architecture, let's address it at that point :)
[16:45] <arraybolt3[m]> Sounds good.
[16:46] <arraybolt3[m]> In the mean time, back to non-shared-object work in LXQt.
[16:46] <tsimonq2> Sounds good!
[16:48] <arraybolt3[m]> (No one cares if I use notes.lubuntu.me as a personal scratchpad do they? I'm using it to keep track of my work since it's markdown features are awesome, especially with tables.)
[16:49] <kc2bez[m]> Go crazy
[16:49] <arraybolt3[m]> Thanks
[16:49] <kc2bez[m]> Sure thing. That's what it is there for.
[23:52] <arraybolt3[m]> teward: Matterbridge seems to be dead. Any time someone sends a file in Telegram, I don't get to see it since the link fails and I don't have Telegram. (I believe it just times out if I try to click the link.)
[23:53]  * arraybolt3[m] pours buckets of coffee into teward's coffee dispenser in trade for fixing it
[23:55]  * arraybolt3[m] uploaded an image: (23KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/fvPQuQPAXjGlDEykdFWebpcU/image.png >
[23:55] <arraybolt3[m]> (Snippet of screen rather than full screen as the URL was shared in -members)
[23:56] <tsimonq2> Man, if only we didn't have to bridge channels ;P
[23:57] <arraybolt3[m]> If I just had a phone I'd sign up for Telegram and problem solved, but therein lies the wrench in the works...