[00:55] <arraybolt3[m]> Hey guys, finally back, sorry for the long delay.
[01:24] <arraybolt3[m]> Simon Quigley (Developer): I hit Lintian output that I don't know how to handle. https://pastebin.com/UvW7m1bj
[01:25] <arraybolt3[m]> Everything else it spit out at me I handled or know how to handle.
[01:28] <arraybolt3[m]> Actually, I do know how to handle the missing manual page message, but I'm still not sure what to do with the other two.
[01:53] <arraybolt3[m]> Dan Simmons Simon Quigley (Developer) teward https://github.com/lubuntu-team/qtxdg-tools-packaging/pull/1
[02:13] <Eickmeyer> arraybolt3[m]: Without knowing the packaging, my guess is the control file shows "Section: libs" and that it contains an application in usr/bin, which tends to throw things off.
[02:14] <Eickmeyer> arraybolt3[m]: According to https://lintian.debian.org/tags/application-in-library-section, you should make an override since it's a false positive as it's a helper application for a library.
[02:14] <arraybolt3[m]> Eickmeyer: Will check, thank you!
[02:15] <arraybolt3[m]> Eickmeyer: Sure enough, you're right. However, it technically "belongs" in libs, since it's not a tool the user will ever use themselves AFAIK, but it does include an executable, which is put in usr/bin.
[02:16] <Eickmeyer> Exactly. Keep the "Section: libs" in the control file, but override the lintian warning.
[02:16] <arraybolt3[m]> Eickmeyer: The proper solution would probably be to mod the code to place it in /usr/lib/libexec, but that might require modding LXQt. I guess I could override the warning, that's not a bad idea. Thank you!
[02:16] <arraybolt3[m]> (Actually, since the package is part of LXQt, modding it would definitely require modding LXQt, but you get what I was trying to say.)
[02:17] <Eickmeyer> As for "wrong-name-for-upstream-changelog", you''ll probably have to just change the installation path with the debian/install file. see https://lintian.debian.org/tags/wrong-name-for-upstream-changelog
[02:17] <arraybolt3[m]> Eickmeyer: OK, thank you!
[02:17] <Eickmeyer> Or, rather, debian/docs
[02:18] <Eickmeyer> Np
[02:18] <Eickmeyer> lintian.debian.org is your friend.
[02:18] <arraybolt3[m]> 👍️
[02:34] <arraybolt3[m]> Ultimately, I just overrode both - I figured out why the bad changelog filename message was getting thrown, and fixing it would require modifying the LXQt package to change the CHANGELOG file to changelog.gz, which is probably not gonna happen, so I just told it to ignore it.
[02:38] <arraybolt3[m]> qtxdg-tools backported.
[04:49] <arraybolt3[m]> Simon Quigley (Developer): OK, so I just started backporting libfm-qt, and I hit an alarming error in Lintian that looks like it may interfere with upgrading from a backport. "E: libfm-qt11: symbols-file-contains-current-version-with-debian-revision on symbol _ZN2Fm12FolderConfig13getStringListEPKcPm@Base and 23 others (libfm-qt.so.11)". So now I need to fight with symbols, but I don't know how to do that, and it looks a bit
[04:49] <arraybolt3[m]> daunting.
[05:44] <arraybolt3[m]> During the testing of the latest Calamares, I noticed the following... bug? If you do not have Internet on a system with the latest Lubuntu Kinetic installation, the Lubuntu Manual is inaccessible. This is to be expected, as the manual is hosted online, but this makes me think perhaps we should create a package containing the manual, and make the manual shortcut point to a local copy of the manual. Perhaps it should even call a
[05:44] <arraybolt3[m]> script that checks for Internet access and loads the online version if possible, falling back to the offline version otherwise.
[05:44] <arraybolt3[m]> This would enable even users without Internet access the ability to access the Lubuntu manual.
 "Simon Quigley (Developer): OK..." <- Oooooooh fun! You ready for symbols??
 "During the testing of the latest..." <- I thought about this but that comes with the downside of Lubuntu Manual being ephemeral. Maybe we could snap it...
[08:18] <tsimonq2> guiverc: Let me know how the Peruvian rice tastes ;)
[09:09] <kc2bez[m]> Don't forget to salt the water as much as you want.
[11:00] <guiverc> :) & LOL
[21:42] <arraybolt3[m]> Hey all, I'm here. Finally. Simon Quigley (Developer) Yeah, guess I'm ready for symbols.
[21:42] <arraybolt3[m]> (I'm three installs into the Calamares testing checklist.)
[21:44] <arraybolt3[m]> Crud, kernel update came through, I'mma have to reboot. BRB
 "guiverc: Let me know how the..." <- What did I miss?
[22:32] <guiverc[m]> arraybolt3: just a 'thank you' (a recipe provided on reddit from memory) 
[22:33] <arraybolt3[m]> guiverc: Ah, thank you for helping me understand!
 "Hey all, I'm here. Finally..." <- Read up...
[22:36] <tsimonq2> https://wiki.debian.org/UsingSymbolsFiles
[22:36] <tsimonq2> https://qt-kde-team.pages.debian.net/symbolfiles.html
[22:36] <tsimonq2> Be prepared for about a five hour mindf*** :)
[22:36] <arraybolt3[m]> Ah, you're here! Sorry to have been gone for so long, things were crazy today. Just found a wildlife camera livestream thing, so that should be calming while fighting with this.
[22:37] <tsimonq2> Very nice :)
[22:37] <tsimonq2> This is probably one of the hardest parts about packaging
[22:38] <tsimonq2> But one of the most important parts 
[22:38] <arraybolt3[m]> Would kinda have been nice if Lintian had told me all the symbols that were messed up, not just "and 23 others" or something... am I going to have to sbuild 23 times?
[22:39] <tsimonq2> Nope, just cheat and use symbolshelper ;)
[22:39] <tsimonq2> You should understand what they are, what they do, and what you're doing when you're updating them though 
[22:39] <tsimonq2> Hint: think library stability. semver.org
[22:40] <arraybolt3[m]> OK. I don't know C or C++ hardly at all, so I don't even know what a library symbol is yet... C# doesn't have such a concept AFAICT, and that's the language I know.
[22:41] <arraybolt3[m]> (Or at least one of the languages I know, but C# is the most low-level, which is silly since it's high-level...)
[22:41] <tsimonq2> tl;dr we list all publicly-available C++ functions exported for use in a file, in C++ garbage format lol
[22:41] <arraybolt3[m]> Oh no.
[22:41] <arraybolt3[m]> When even a dev thinks something is in garbage format, that's when you know you've got a problem.
[22:42] <tsimonq2> I mean it's not human-readable no matter how hard I stare at it lol
[22:42] <tsimonq2> c++filt is your friend 
[22:42] <arraybolt3[m]> This is doable without knowing more than the most basic of C++, right?
[22:42] <tsimonq2> Mostly yeah
[22:44] <arraybolt3[m]> For C++ libraries it is often better not to ship symbols files. From the Debian thing you linked to.
[22:44] <tsimonq2> LMAO
[22:44] <tsimonq2> lazy
[22:45] <arraybolt3[m]> I don't know how to use "sed" either. Should I start there?
[22:45] <tsimonq2> arraybolt3[m]: That's a pretty good tool to learn how to use
[22:46] <arraybolt3[m]> OK. I usually take the easy route when it comes to Linux stuff, but I guess there's a time for everything.
[22:51] <arraybolt3[m]> OK, wait. One of these things has me using pkgkde-symbolshelper, is this even for non-KDE stuff?
[22:56] <arraybolt3[m]> Ah, so that's why the symbol names in C++ are so messy! http://nickdesaulniers.github.io/blog/2016/08/13/object-files-and-symbols/
[22:58] <arraybolt3[m]> And why you said to use C++filt. OK, I'm tracking. This is complex, but at least makes sense.
[23:10] <arraybolt3[m]> Simon Quigley (Developer): So, quick question, I think I understand what a symbol is now, and what they do, but the particular symbol Lintian is griping about isn't even in the symbols file for libfm-qt. So...?
[23:10] <arraybolt3[m]> Does this mean I need to recreate the symbols file entirely?
[23:26] <arraybolt3[m]> * non-KDE stuff? (nevermind, figured this one out)
 "Does this mean I need to..." <- Nope, in fact I would encourage you not to
[23:32] <tsimonq2> In the sbuild log, there's a diff
[23:32] <arraybolt3[m]> Ah, nice. I read about there being a diff when using dpkg-buildpackage. So SBuild makes one too. Nice.
[23:32] <tsimonq2> Apply the diff and only leave the upstream version, then upload to a test PPA with all arches enabled to get symbols for all arches (which will change)
[23:33] <tsimonq2> arraybolt3[m]: Nah it's the same thing we're talking about :)
[23:33] <arraybolt3[m]> So Lintian is griping about symbols that the build just generated?
[23:33] <arraybolt3[m]> Thus why it complains about the Debian revision?
[23:33] <tsimonq2> arraybolt3[m]: Yeah
[23:33] <arraybolt3[m]> Nice, that makes sense.
[23:33] <tsimonq2> The new ones that were generated by the new upstream release
[23:34] <arraybolt3[m]> I was gonna say, "why on EARTH is it griping about a symbol that doesn't even exist?!"
[23:40] <tsimonq2> Heh :)
[23:46] <arraybolt3[m]> Simon Quigley (Developer): OK, I think I'm supposed to manually grab the diff out of the build log, here's what I grabbed, tell me if I got it right. The first and last line are outside of the diff (I think), everything else belongs inside (I think). https://pastebin.com/i8erY3jW
[23:52] <arraybolt3[m]> Simon Quigley (Developer): Or do I plop the whole buildlog in there even though it's an sbuild log and not a dpkg-buildpackage build log?
[23:53] <tsimonq2> Just the diff, the KDE tooling can do it automatically 
[23:53] <tsimonq2> I wish we had a CI again...