[00:23]  * guiverc thanks teward 
[00:24]  * teward pushes guiverc into the lake
[00:24] <teward> sometimes being coredev is VERY useful xD
[00:24] <arraybolt3_> Eickmeyer: ?
[00:25] <arraybolt3_> Push commits to where?
[00:25] <Eickmeyer> arraybolt3_: calamares-settings-ubuntu
[00:25] <arraybolt3_> I mean which Git repo?
[00:25] <arraybolt3> git.lubuntu.me
[00:25] <arraybolt3> ?
[00:25] <Eickmeyer> Yes.
[00:25] <Eickmeyer> The only one we have for it.
[00:25] <teward> arraybolt3: I was wondering when you were going to realize you had toilet paper hanging off your shoe :P
[00:26] <arraybolt3> Gah, I did entirely forget to do that.
[00:26] <arraybolt3> Sorry about that.
[00:26] <Eickmeyer> Well, you're going to want to re-clone now because your local branch is bonkers.
[00:26] <arraybolt3> Eickmeyer: We also had it on GitHub at one point (might still have it there) so I thought maybe that was a point of confusion, but nope, it's just me being forgetful.
[00:27] <Eickmeyer> arraybolt3: The github repo has only ever been a mirror of git.lubuntu.me
[00:27] <arraybolt3> Gah, I must have been in way too much of a hurry. Not only did I not push my commit, I didn't even remember to commit locally.
[00:28] <arraybolt3> So I just "git reset --hard HEAD; git pull" and that fixed it.
[00:28] <Eickmeyer> Well, that's another way to do it.
[00:28]  * arraybolt3 arbitrarily blames teward for the whole incident
[00:28] <RikMills> https://code.launchpad.net/~ubuntu-qt-code/+git/calamares-settings-ubuntu
[00:29] <RikMills> IIRC
[00:29] <Eickmeyer> Meh, doesn't matter. The fact of the matter is that code was 1) not committed, and 2) not pushed. Caused problems this morning.
[00:30] <arraybolt3> I see that. And I wasn't on all day, so I didn't see any of the gripes until it was way too late.
[00:31] <Eickmeyer> And sorry for griping, but I know that you know better. Also, the changelog needed to be more specific on which slideshow you were updating.
[00:31] <Eickmeyer> Just making you a better dev, that's all. :)
[00:31] <arraybolt3> +1
[00:34] <teward> guiverc: told you i'd get it all fixed for torbrowser-launcher.  but Debian had to unfubar things.  and a sync just works now so :)
[00:36] <guiverc> thanks teward ; I'll hopefully be able to do the fb UWN publish on this box on my-tue morn :)
[00:37] <Eickmeyer> teward: TG when you get a chance (no rush, just personal stuff).
[00:44] <arraybolt3> Eickmeyer: I have a checklist for each upload I do from now on that should help me to avoid these problems in the future. Thanks for your patience and for grilling me instead of just silently fixing things and hoping I'd remember right next time.
[00:46] <Eickmeyer> arraybolt3: Awesome! The more you do it, the more it'll just become habit. Also, don't forget the tags.
[00:46] <arraybolt3> Gah, I *always* forget those until the upload after. We have a rule to not tag until the upload goes to to -release or -updates (I think?), and I never manage to check that until the day after the upload most of the time.
[00:48] <arraybolt3> I can get around that by tagging locally and then pushing the tags the next day after checking LP, though.
[00:51] <Eickmeyer> Well, I habitually tag upon upload to the development version. Tags are easy to delete and push --force if necessary. Once it's in proposed, even if it gets removed, it'll have to be version bumped anyhow.
[00:52] <Eickmeyer> As far as SRUs (updates repository), I wait until it's accepted. Then it goes into proposed. At that point, you'll have to, again, version bump if something goes wrong, so you might as well tag.
[00:53] <arraybolt3> Hmm. I see "once the upload is accepted" is when we tag. I only just now realized that means that when I get the "(Accepted)" email back, it's time to tag.
[00:53] <arraybolt3> I kept thinking "accepted" meant "in -release or -updates".
[00:54] <arraybolt3> Sigh. The more you know, the more you learn how much you don't know.
[00:54] <Eickmeyer> "accepted" means "in -proposed". 
[00:54] <Eickmeyer> At least, in this context.
[00:55] <arraybolt3> Makes sense. And LP doesn't (usually!) take forever to do that.
[00:55] <arraybolt3> Anyway, good tips, will follow.
[00:55] <Eickmeyer> 👍
[20:55] <arraybolt3> w.r.t. Openbox crash, there's hope! https://bugzilla.icculus.org/show_bug.cgi?id=6669
[20:55]  * arraybolt3 adds that to the bug report on LP
[20:56] <arraybolt3> Oh, that's already attached.
[20:56] <arraybolt3> I missed that there was a patch for it.
[21:03] <arraybolt3> Hmm, two patches in fact.
[21:08] <arraybolt3> I guess now the question is which of the two is better.
[21:15] <arraybolt3> I don't have enough knowledge about Openbox and C in general to be sure, but I *think* the patch on the Arch Linux BBS is probably superior here. The other patch on the Openbox bug report simply copies a specific list, uses it, then discards it, which on the surface feels like it's masking whatever's really going wrong. The Arch Linux patch doesn't do a list copy, but instead "sanitizes" the list (not exactly sure what that means in 
[21:15] <arraybolt3> this context). Which feels like a more right way of doing things, but I don't know for sure.
[21:16] <arraybolt3> Anyway, https://bugzilla.icculus.org/attachment.cgi?id=3646&action=edit is the list-copy patch, while https://bbs.archlinux.org/viewtopic.php?pid=2090570#p2090570 has the other patch.
[21:24] <arraybolt3> I'll probably try and implement the Arch Linux one if no one has any objections.
[21:24] <arraybolt3> er, not implement, but patch in... you know what I'm trying to say.
[23:34] <arraybolt3> OK, I have an experimental patch made, let's see how this goes.
[23:44] <arraybolt3> Well, it compiles, but I don't understand fully why it works. I don't feel comfortable pushing code that I don't understand into production, and I know or can learn enough to figure out what I'm looking at. Beta Freeze isn't until the 27th, so I think I should take time to figure out what the code is supposed to do and why it's not doing it.
[23:45] <arraybolt3> (Obviously, if someone else gets to it first, feel free to take it.)
 guiverc: test lunar torbrowser-launcher if you want to make sure it fixes that bug
 if it does then I"ll have to ask the TB for a one time MRE to push this all via SRUs
[23:48] <guiverc> ack... downloading now (no 404) so thanks @teward001  (primary box; not live but live will be there in a day if not already)
[23:51] <guiverc> yep... working, so thank you Good Sir. 
 guiverc: ack.  Fix Released for Lunar.  Speical one time SRU/MRE request made again to the SRU / Release team to get that backported as 0.3.6-2 for older releases :P
[23:57] <guiverc> :)   That'll make some users happy  (and those of us looking at support sites get fewer reminders of issue; thank you again!)
 ye well because it's 0.3.(1ish) to 0.3.6 and upstream interlaces features as well as bugfixes
 i have to get a special OK
 note i'm going to eventually see if this is snappable
 which might just solve that problem going forward
 but it's a side project
 not a primary