 guiverc: can you see if https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/2002875 is the same bug / cause?
[00:27] -ubottu:#lubuntu-devel- Launchpad bug 2002875 in torbrowser-launcher (Ubuntu) "torbrowser-launcher crashed with FileNotFoundError in check_min_version(): [Errno 2] Datei oder Verzeichnis nicht gefunden: '/home/username/.local/share/torbrowser/tbb/x86_64/tor-browser_de/Browser/TorBrowser/Docs/ChangeLog.txt'" [Medium, New]
 my brain is ERR:ZERO ENERGY
 so i'm headed right to bed.
[00:33]  * guiverc doesn't read deutuche :(  but my system has file ~/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/TorBrowser/Docs/ChangeLog.txt  (using Lubuntu/LXQt... I could logout & switch to GNOME to check there, but I suspect it'll be found there too)
[00:33] <guiverc> @teward001, ^
[00:39]  * guiverc left comment on bug report ^  (& subscribed if you want/need to ask questions etc; pinging me is worthwhile to ensure I see it)
[01:16] <arraybolt3> WOOHOO I think I just figured it out!
[01:16] <arraybolt3> The Openbox crash is happening during some sort of "window recalculating" function. While I don't know exactly what that function does, it has a part where it ends up with two pointers to the same list.
[01:17] <arraybolt3> It then uses one of those pointers in a loop, but the code in the loop proceeds to modify the list in ways that throw the used-in-a-loop pointer off, but leave the original pointer valid.
[01:17] <arraybolt3> The second time through the loop, the now-wonky pointer is used to try and dereference a value, and Openbox segfaults.
[01:18] <arraybolt3> The solution in the Arch Linux patch is to "reset" the pointer every time the list-modifying code is executed.
[01:18] <arraybolt3> *the patch on the Arch Linux forums I mean
[01:20] <arraybolt3> It appears to be a slower solution, but it works. The other alternative would be to figure out how to "fix" the used-in-a-loop pointer every time the list is modified by the loop.
[01:20] <arraybolt3> Or simply work off two lists, which is what the patch on the Openbox bug report does.
[01:21] <guiverc> :)  & Well done arraybolt3 
[01:21] <arraybolt3> (It basically copies the list that is being modified, then uses the copy (which is not modified) for the pointer used by the loop.)
[01:21] <arraybolt3> guiverc: Well don't congratulate me yet, I've not tested any of this, I just finally had things click after staring at the code for a bit :P
[01:22] <arraybolt3> I think I'm going to try and figure out how to fix the pointer each time the list is modified, rather than resetting it.
[01:22] <guiverc> understanding the issue is the start for a fix; to me that's success (even if not yet realized!)
[01:22] <arraybolt3> :) Thanks
[01:24]  * guiverc quit using lubuntu/lxqt a few days ago as openbox was crashing too often... used xubuntu/xfce a day or so, then ubuntu/gnome 1.5 days but back on lubuntu/lxqt but switched out openbox for xfwm4 to avoid annoying crashes
[01:24] <arraybolt3> Hmm, it dawns on me that figuring out how to "fix" the pointer may be impossible, since the list is a linked list, not an indexed one like I'm used to.
[01:24] <arraybolt3> So to get to a point in the list, you *have* to walk through it.
[01:26] <arraybolt3> And the code on the Arch Linux forums uses a hopefully-fairly-efficient method of identifying when to stop walking through the list IIRC. So I think I'm just going to patch that in, give credit to the patch author, and throw it in a PPA for testing.
[01:26] <guiverc> :)
[01:26] <arraybolt3> Though... perhaps there's a way to save where I am in the list...
[01:26] <arraybolt3> ok I'll stop talking out loud and get back to hacking.
[01:26] <arraybolt3> *thinking out loud
[01:45] <arraybolt3> Building current patch now, will report the results shortly.
[01:45] <arraybolt3> *building with current patch
[01:53] <arraybolt3> guiverc: The patch works!
[01:53] <arraybolt3> OK, will push to a PPA and have available for testing shortly.
[01:54] <guiverc> :)   (but also followed by a rather quick :(  as that'll require me to make a change (to test) & then LOGOUT so I can re-login; the logout is the :( )
[02:09] <arraybolt3> https://launchpad.net/~arraybolt3/+archive/ubuntu/openbox
[02:11] <guiverc> thank you arraybolt3 ; I'll aim to switch to it in 30-60+ mins
[02:11] <arraybolt3> Thanks!
[02:14] <guiverc> grr  i just noted day; I didn't note UWN notice up for review (box wasn't online in time) which I'll do first too, maybe 60-75min+
[03:25] <guiverc> arraybolt3, did you install from the PPA; I'm getting "Version '3.6.1-10ubuntu1~ppa1' for 'openbox' was not found" 
[03:25] <guiverc> nope, ignore; sudo apt update & now it's found...  (2x libs too!)
[03:27]  * guiverc checks my 'fire insurance'...
[03:35] <guiverc> quick play and no crashes (or FIRES!) arraybolt3 ; I'll use normally; but I was getting openbox crash maybe hourly as I recall prior to fix  (why I switched to other DEs then swapped out openbox).. currently using 3.6.1-10ubuntu1~ppa1
[03:37] <arraybolt3> guiverc: \o/ I only modified one function, so it's possible other conditions could cause crashes. So just be prepared for that, and if it happens yell at me to try and find what's wrong. (I think this is likely going to be sufficient though.)
[03:40] <guiverc> my normal usage was triggering the openbox crash... but it may take a couple of days for no-crashes to be confirmed as it wasn't all behaviors
[03:41] <guiverc> (I could go 5-6 hours without crash; yet doing a different task get 3 in an hour causing me to switch DE)
[03:42] <arraybolt3> I bet every time you started getting crashes you had *something* in fullscreen mode?
[03:42] <guiverc> yep sure did !
[03:42] <arraybolt3> (The code that caused the crash specifically dealt with fullscreen windows.)
[03:44] <guiverc> my bug report mentioned F11 on browser before opening new window.. to re-create.. reviewing UWN earlier I would have used F11 to make it fullscreen (increased size x3) ; moved to exercise bike (behind me) & then read...   use F11 a bit ...
 yes I think I had fullscreen video playing for a lot of the crashes as well or at least something maximized
[17:39] <Eickmeyer> Has anybody noticed issues with cala not taking the colors specified in branding.desc? for the sidebar?
[18:23] <arraybolt3> Not here yet.
[18:24] <arraybolt3> Did the sidebar black out again?
[18:24] <Eickmeyer> No, it just won't obey the colors. The text is black when highlighted.
[18:24] <Eickmeyer> Tried changing it, no dice.
[18:25] <arraybolt3> Ugh, weird. Check capitalization in the branding.desc fields, that's what bit us last time.
[18:25] <Eickmeyer> I'll see if they match what you have.
[18:25] <arraybolt3> something like sidebarBackgroundColor failed, but SidebarBackgroundColor worked, or something similar to that.
[18:25] <arraybolt3> Back when we had the black sidebar.
[18:29] <Eickmeyer> Yeah, I remember that, but that was fixed.
[18:39] <Eickmeyer> arraybolt3: To be clear, the background isn't a problem, it's the text that's selected that I'm having difficulty with.
[18:41] <arraybolt3> Right, that's what I thought. I'll do some digging in Lubuntu to see if it's Studio-specific or not.
[18:41] <Eickmeyer> I'm digging in cala's github.
[18:41] <arraybolt3> It's probably not specific to Studio, I would guess.
[18:43] <Eickmeyer> Nope, they changed the parameters.
[18:43] <Eickmeyer> s/SidebarTextSelect/SidebarTextCurrent
[18:43] <Eickmeyer> Definitely not studio specific.
[18:44] <Eickmeyer> https://github.com/calamares/calamares/blob/calamares/src/branding/default/branding.desc#L185
[18:45] <Eickmeyer> Yep, that certainly fixed it.
[18:51] <Eickmeyer> tagged, pushed, uploaded.
[18:52] <Eickmeyer> arraybolt3: If you have any problems on the Lubuntu side, you might want to do the same.
[18:52] <arraybolt3> I've not noticed any, but it may be wise to change things just so we don't have invalid parameters floating around.
[18:53] <arraybolt3> If that's allowed this late in the cycle that is.
[18:53] <Eickmeyer> Any bugfixes are. What I just did was a UI change that was a bugfix.
[18:54] <arraybolt3> Right but I don't know if changing an invalid parameter that's not manifesting itself to the user in Lubuntu qualifies as a bug fix.
[18:54] <arraybolt3> I guess though it is a bugfix since the parameter we use is probably wrong, and wrong things ought to be fixed.
[18:54] <Eickmeyer> It's not a critical bugfix, probably not a high bugfix, but a medium bugfix. In my case, it was a high bugfix but not a critical one, but since I didn't have any critical ones hanging over my head, there we go.
[18:55] <arraybolt3> +1
[18:56] <arraybolt3> We have a critical one :P but there's a fix for it, just waiting a couple of days while it gets a good workout since we're adding a non-upstream patch written by a newbie C coder (me) into Openbox :P
[18:56] <Eickmeyer> Either way, you certainly know it's throwing errors.
[18:57] <Eickmeyer> Ah, good call on that.
[20:25] <arraybolt3> @kc2bez: Makes sense, will do.
[21:06] <krytarik> So my expiry from ~lubuntu-art is due again soon.. would anybody from the council be so kind and renew my membership on it once more? XD
[21:53] <arraybolt3> krytarik: Done.
[21:53] <arraybolt3> (Also, if you see three emails about a status change, that's because I didn't know how the renewal buttons work and fumbled twice trying to do it :P)
[21:54] <arraybolt3> (Kept accidentally setting the expiration date a day too early, figured it out after a couple of tries.)
[22:38] <guiverc> fyi arraybolt3 , have had no openbox crashes...
[22:42] <arraybolt3> guiverc: Nice!
[22:42] <krytarik> arraybolt3: Thanks!
[22:43] <krytarik> And well, as it turns out the member doesn't get any emails at all about this.. XD
[22:44] <arraybolt3> :P
[22:52] <arraybolt3> Eickmeyer: You appear to have forgotten to make a new changelog entry for the Ubuntu Studio SidebarTextCurrent field change?
[22:53] <arraybolt3> It didn't make it to Git at least.
[22:53] <arraybolt3> Yeah the entry's there, just not in Git. Fixing now.
[22:54] <Eickmeyer[m]> rechecking...
[22:54] <Eickmeyer[m]> No, don't fix.
[22:54] <Eickmeyer[m]> I may have forgotten to push.
[22:55] <Eickmeyer> arraybolt3: Fixed.
[22:56] <Eickmeyer> In those instances, I can fix a lot faster than you creating a debdiff. That's part of why I was pinging you on Saturday morning.
[22:56] <Eickmeyer> (also retagged)
[22:57] <arraybolt3> Ah. That makes sense.
[22:57] <arraybolt3> (My Matrix client failed to "bing!" me when you sent stuff so I actually finished fixing, then tried to push and couldn't figure out why it was being rejected :P glad I checked
[22:58] <Eickmeyer> Because I'm fast as fluff boi!
[23:11] <arraybolt3> Darn it, I forgot to add an (LP: #XXXXXX) to the changelog entry.
[23:11]  * arraybolt3 scribbles that into the checklist
[23:33] <Eickmeyer> Yeah, that's especially important if you want to avoid an SRU reject.
[23:34] <arraybolt3> Well this isn't an SRU, just an upload in Lunar.
[23:34] <arraybolt3> But I do have that as part of my checklist now.
[23:35] <Eickmeyer> Obviously, I was just saying it as a good idea.