2019-12-30 GnuCash IRC logs
00:03:40 *** omnireq has quit IRC
00:04:01 *** puck has quit IRC
00:05:59 *** omnireq has joined #gnucash
00:05:59 *** ChanServ sets mode: +v omnireq
00:06:52 *** Aussie_matt has quit IRC
00:08:06 *** GabrieleV has quit IRC
00:09:22 *** puck has joined #gnucash
00:20:21 *** Gerd has joined #gnucash
00:25:10 *** omnireq has quit IRC
00:25:20 *** omnireq has joined #gnucash
00:25:20 *** ChanServ sets mode: +v omnireq
00:28:40 *** boldstripe has quit IRC
00:29:35 *** boldstripe has joined #gnucash
00:51:24 *** Cuare has joined #gnucash
00:51:25 *** ChanServ sets mode: +v Cuare
01:07:58 *** Mechtilde has joined #gnucash
01:08:09 *** GabrieleV has joined #gnucash
01:12:05 *** frakturfreak has quit IRC
01:23:30 *** jervin has quit IRC
01:26:11 *** frakturfreak has joined #gnucash
01:26:11 *** ChanServ sets mode: +v frakturfreak
01:30:19 *** jervin has joined #gnucash
01:35:59 *** CrashCart has joined #gnucash
01:36:25 *** Cuare has quit IRC
01:39:00 *** Mechtilde has quit IRC
01:41:03 *** CrashCart has quit IRC
01:53:54 *** jervin has quit IRC
01:57:59 *** fell has joined #gnucash
01:58:00 *** ChanServ sets mode: +o fell
01:59:37 *** fell_laptop has quit IRC
02:09:10 *** omnireq has quit IRC
02:11:30 *** omnireq has joined #gnucash
02:11:31 *** ChanServ sets mode: +v omnireq
02:19:34 *** Guest36 has joined #gnucash
02:29:21 *** boldstripe has quit IRC
02:30:15 *** boldstripe has joined #gnucash
02:30:40 *** omnireq has quit IRC
02:33:00 *** omnireq has joined #gnucash
02:33:01 *** ChanServ sets mode: +v omnireq
02:52:10 *** omnireq has quit IRC
02:54:30 *** omnireq has joined #gnucash
02:54:31 *** ChanServ sets mode: +v omnireq
03:02:43 *** Cuare has joined #gnucash
03:02:44 *** ChanServ sets mode: +v Cuare
03:13:40 *** omnireq has quit IRC
03:16:00 *** omnireq has joined #gnucash
03:16:02 *** ChanServ sets mode: +v omnireq
03:17:02 *** Han has joined #gnucash
03:25:15 *** gjanssens has joined #gnucash
03:25:15 *** gncbot sets mode: +o gjanssens
03:25:15 *** ChanServ sets mode: +o gjanssens
03:35:10 *** omnireq has quit IRC
03:36:25 *** omnireq has joined #gnucash
03:36:25 *** ChanServ sets mode: +v omnireq
03:52:51 *** Mechtilde has joined #gnucash
04:12:33 *** fell has quit IRC
04:12:40 *** fell has joined #gnucash
04:12:40 *** ChanServ sets mode: +o fell
04:21:41 *** fell has quit IRC
04:30:01 *** boldstripe has quit IRC
04:30:55 *** boldstripe has joined #gnucash
04:59:36 *** fell has joined #gnucash
04:59:37 *** ChanServ sets mode: +o fell
05:05:17 *** User_ has joined #gnucash
05:07:22 <gjanssens> .
05:41:23 *** g38 has joined #gnucash
05:42:45 <g38> hello. I am using gnucash 3.7 on a Fedora 31. A few weeks ago a change occurred in the way that gnucash autocompletes the text fields while typing. The new behaviour is very annoying. I am not sure if it is a change in gnucash or perhaps in Gnome or somewhere else (though I have noticed it only in gnucash)
05:44:06 <g38> Concretely, when I type something that gnucash already knows about, the previous behaviour was: display the guess but let the user type what he will, the new behaviour is: as soon as the guess is uniquely determined, let the cursor jump to the end of the text (so that if the user unnoticingly continues to type, the result is messed up)
05:44:15 <g38> does anyone know what I am talking about?
05:51:39 *** Mechtilde has quit IRC
06:12:26 *** User_ has quit IRC
06:15:17 *** FH_thecat has joined #gnucash
06:21:23 *** chris has joined #gnucash
06:21:23 *** ChanServ sets mode: +v chris
06:21:36 <chris> .
06:25:12 *** dfg has quit IRC
06:25:31 *** dfg has joined #gnucash
06:27:19 *** Han has quit IRC
06:30:42 *** boldstripe has quit IRC
06:31:37 *** boldstripe has joined #gnucash
06:48:35 *** dfg has quit IRC
06:53:46 *** Mechtilde has joined #gnucash
06:56:55 *** Mechtilde has quit IRC
06:58:57 *** Mechtilde has joined #gnucash
07:11:37 *** Guest36 has quit IRC
07:16:53 *** warlord has joined #gnucash
07:34:59 *** monkeyjuice has joined #gnucash
07:41:22 *** monkeyjuice has quit IRC
07:48:21 <gjanssens> jralls: I had a bit of an issue when trying to update gnucash on flathub because gnucash and gnucash-docs were tagged differently
07:49:11 <gjanssens> gnucash was at 3.8b while gnucash-docs wasn't tagged at all yet
07:49:23 *** Gerd has quit IRC
07:49:31 *** Gerd has joined #gnucash
07:50:10 <gjanssens> As the flatpak build scripts (until now) have required the tags to be the same for gnucash and gnucash-docs I have pushed the same set of tags to gnucash-docs.
07:50:47 <gjanssens> Unfortunately that was still not sufficient; the tarballs were named after their tags so they were versioned differently.
07:51:41 <gjanssens> I first tried to rename the gnucash-docs tarball to 3.8b, but had to retar it to make the extraction directory 3.8b as well
07:52:49 <gjanssens> That was still not enough - the sourceforge directory was still 3.8 and not 3.8b, so the script tripped over that as well.
07:53:15 <gjanssens> Tried to make a softlink (via ssh on the sourceforge server), but the webinterface can't handle that
07:53:22 <gjanssens> And then I goofed :(
07:53:39 <gjanssens> I decided to delete the softlink via the sourceforge webinterface.
07:54:02 <gjanssens> And learned softlinks work enough to then delete the original directory. Oops.
07:54:22 <gjanssens> Luckily all data was also on github, so restoring the directory was not too hard.
07:54:42 <gjanssens> But with that you are up do date of what happened.
07:55:15 <gjanssens> As all of that didn't help with the flatpak builds, I refined the build script a bit to accept a few more parameters
07:55:57 <gjanssens> So from now on we can pass a release number via -r and code and documentation tags via -c and -d
07:56:29 <gjanssens> That should relax the file/directory naming restrictions a bit.
07:56:56 <gjanssens> I have also updated the release process wiki page with this info.
07:57:52 <gjanssens> So on the next release can you try the flatpak build steps as well ?
08:13:43 *** monkeyjuice has joined #gnucash
08:27:38 *** chris has quit IRC
08:30:55 *** chris has joined #gnucash
08:30:55 *** ChanServ sets mode: +v chris
08:31:22 *** boldstripe has quit IRC
08:50:00 *** chris has quit IRC
08:56:41 *** Gerd has quit IRC
09:04:51 *** chris has joined #gnucash
09:04:52 *** ChanServ sets mode: +v chris
09:19:37 *** fell has quit IRC
09:21:20 *** boldstripe has joined #gnucash
09:47:32 <chris> gjanssens I'm happy to state that I don't actually have a consistent masterplan in debugging reports :)
09:48:39 <chris> with little knowledge of internals other than my own experimentation, and trying to decode C afterwards, I try to make things half-decent
09:48:48 <chris> hence your input always valuable
09:49:11 <chris> I think for new-owner-report it's close to perfect
09:53:07 *** jervin has joined #gnucash
09:53:22 *** monkeyjuice has quit IRC
09:55:51 <gjanssens> well chris, thanks for your patience with me. I sometimes need many attempts before I manage to get my views across...
09:55:54 *** jervin has quit IRC
10:14:14 *** jervin has joined #gnucash
10:17:05 *** jervin has quit IRC
10:17:10 *** omnireq has quit IRC
10:19:30 *** omnireq has joined #gnucash
10:19:32 *** ChanServ sets mode: +v omnireq
10:22:01 *** omnireq has quit IRC
10:30:39 *** Mechtilde has quit IRC
10:48:38 *** delli3 has joined #gnucash
11:03:47 *** omnireq has joined #gnucash
11:03:49 *** ChanServ sets mode: +v omnireq
11:09:44 *** ArtGravity has joined #gnucash
11:09:44 *** ChanServ sets mode: +v ArtGravity
11:15:10 <g38> Hello, has anyone else noticed a change in the way gnucash autofills text entries when one types something not for the first time?
11:45:21 *** fell has joined #gnucash
11:45:22 *** ChanServ sets mode: +o fell
11:47:40 *** fell has quit IRC
11:51:50 *** fell has joined #gnucash
11:51:50 *** ChanServ sets mode: +o fell
12:12:23 *** Gerd has joined #gnucash
12:17:48 *** guak has joined #gnucash
12:30:47 *** Mechtilde has joined #gnucash
12:44:31 <jralls> gjanssens, I should probably practice with the flatpak scripts before the next release. I've been holding off on that stuff until warlord gets moved in.
12:44:39 <jralls> g38: Nope.
12:44:50 *** g38 has quit IRC
12:50:54 *** jervin has joined #gnucash
12:50:59 <jralls> gjanssens, fell Perhaps we need to think a bit more about tags and releases. In my mind the release yesterday was version 3.8, not 3.8b. I had to retag twice because of cstim's last-minute gyrations with uk.po and zh_CN.po and then because the Slackware packager discovered that a new cmake module had been left out of the dist.
12:54:21 <jralls> I changed the tarball names because https://wiki.gnucash.org/wiki/Release_Process#Source_tarballs says to. That might be misguided because it results in a disconnect between the tarball name and the reported version.
12:56:13 *** guak has quit IRC
12:56:42 <jralls> The alternative is to change the version number in CMakeLists.txt to correspond to the retag, but that introduces version number weirdness.
12:58:45 <jralls> The other alternative is to leave the tarball and bundle names alone: It's the 3.8 release and the tag is a detail that most users and packagers needn't worry about.
13:05:50 *** jervin has quit IRC
13:07:47 *** g38 has joined #gnucash
13:21:29 *** guak has joined #gnucash
13:24:57 *** gncbot has joined #gnucash
13:27:18 *** g38 has quit IRC
13:44:18 *** bertbob has quit IRC
13:47:04 *** bertbob has joined #gnucash
13:47:05 *** ChanServ sets mode: +v bertbob
13:52:42 *** bertbob has quit IRC
13:53:45 *** bertbob has joined #gnucash
13:53:46 *** ChanServ sets mode: +v bertbob
14:08:54 *** fell has quit IRC
14:09:13 *** fell has joined #gnucash
14:09:15 *** ChanServ sets mode: +o fell
14:20:06 *** KevinDB has quit IRC
14:21:40 *** KevinDB has joined #gnucash
14:21:41 *** ChanServ sets mode: +v KevinDB
14:25:08 *** KevinDB has quit IRC
14:26:35 *** KevinDB has joined #gnucash
14:26:36 *** ChanServ sets mode: +v KevinDB
14:32:34 *** KevinDB has quit IRC
14:35:22 *** KevinDB has joined #gnucash
14:35:22 *** ChanServ sets mode: +v KevinDB
14:36:34 <gjanssens> jralls: what's the downside of moving a tag to another commit, rather than creating a new tag ?
14:36:54 <gjanssens> Would it cause repository sync issues ?
14:40:06 <jralls> https://git-scm.com/docs/git-tag#_discussion
14:41:35 *** Gerd has quit IRC
14:43:36 *** Gerd has joined #gnucash
15:24:58 *** RF has joined #gnucash
15:26:57 <RF> Hello, I started using GNUCASH and I'm reading through the User Guide. Please help me define an account.
15:27:56 <RF> Me and my GF pay for Utilities \ Groceries together. At the end of each month we examine how payed more and we reconcile.
15:29:05 <RF> How would you define such an account? For example - If I pay 100$ for groceries in the end of the month my GF will return 50$ to me. And vice versa.
15:32:46 <gjanssens> jralls: ok. That's clear. I knew that was the case for branches, but was unsure for tags.
15:32:53 <gjanssens> Makes sense though.
15:35:08 <gjanssens> Going back to your initial thought on only using the tags as internal details and leave tarball and bundle names alone
15:35:42 <gjanssens> I think we should look at tarballs and bundle names separately
15:36:32 <gjanssens> Well, not really, but bundles may already have an extra version component if it needs fixes after the official tarball release
15:36:43 <gjanssens> That part is not relevant at this point.
15:38:27 <gjanssens> If tarball and tag names go out of sync, that can equally cause confusion for people trying to match repo with tarball.
15:39:31 <gjanssens> (sorry got to go for dinner)
15:55:11 <jralls> RF An account is a bucket for accumulating transaction information. One way to handle your grocery-cost splitting would be to have a single Expenses:Groceries and an Assets:Bank:Checking for each of you. Then you can use the Cash Flow Report on the Expenses:Groceries account to tell you how much of the grocery expenses for the month were from each checking account.
15:57:29 *** Han has joined #gnucash
15:57:32 <RF> jralls. Thanks. But I want to be able to mark SOME transactions as "money I spend on both of us" from any bucket\account - to keep track of it and then, according to how much my GF spent - to reconcile.
15:59:00 <RF> So for example - I would like to be able to pay for groceries for both of us using my Cash account but also to keep track of the transaction in some other bucket. Is it possible?
15:59:49 <RF> I thought of a liability account - for example - if my GF bought us something. It would pay from there. But if I want to pay - the money is from my Cash or Credit card. So it won't cover the liability
16:00:19 <jralls> gjanssens: If there's only one tarball one could logically assume that it's for the last tag, i.e. gnucash-3.8.tar.gz is for 3.8b. In the event that (like reporter of bug 797536) that you got an earlier tarball you can use gnc-vcs-info.h to see the tag.
16:02:34 <jralls> RF: In accounting any particular transaction involves at least one debit to one account and at least one credit to another. There can be more than one account in each column but the two columns have to add up.
16:04:08 <RF> True. That is true in Life. If I pay for goods - it goes down from my credit card and enters the shop's pocket. But if for example I want to track specific transactions, Can I? Can I tag them?
16:04:35 <RF> and Can I create fictitious account for my GF (her money) which pays for something. and then to see how paid more?
16:04:43 <jralls> So if you spend $50 on groceries from your cash-in-wallet account you credit that and debit Expenses:Groceries for the $50. You could do the same for another pair of shadow accounts and everything would stay in balance though your book would be a bit weird.
16:06:01 <Simon> I assume you're only tracking *your* accounts?
16:06:32 <Simon> so every Groceries transaction would go 50/50 into your Expenses and a debt Asset for your GF to pay
16:06:33 <jralls> There are several free-text fields in each transaction that you can use, but it's up to you to make the entries consistent if you want to use them for filtering.
16:06:51 <Simon> but that doesn't really help you total them up
16:07:29 <Simon> if you want to split money spent on yourself vs on both of you then just use two separate Expenses accounts
16:07:51 <Simon> you can then see how much you spent on each expense type in each period of time
16:09:35 <jralls> Right. Hence the "fake" account for his GF's grocery expenses. It would be a pair of accounts, Income:GF and Assets:GF so the flow for a grocery run would be cr income:gf dr assets:gf, cr assets:gf, dr expenses:groceries.
16:13:13 <RF> that's complicated.. I think we will stick to a simple spreadsheet for tracking how paid for what.
16:13:31 <RF> Maybe I'll give it a try once I'm more familiar with the program. Thanks anyway
16:28:31 *** RF has quit IRC
16:28:58 <gjanssens> jralls: tbh I actually prefer tag names to match tarball names
16:29:56 <gjanssens> Let's take a step back: what we really want is to release 3.8. If things need fixing while doing the release, that's really internal kitchen.
16:30:27 <gjanssens> I prefer to consider a release as an atomic event.
16:30:47 <gjanssens> Moving tags during release should be possible.
16:31:20 <gjanssens> Considering the link you posted earlier, that implies release tags should not be public until the release is complete
16:31:57 <gjanssens> As the Macos release builds happen directly on your system, that's already the case for that bundle
16:32:24 <gjanssens> Only the Windows installer currently depends on a public presence of the tag
16:32:44 <gjanssens> Perhaps we can change that bit instead ?
16:33:28 <gjanssens> For example have special clones for release only on code.gnucash.org's gitolite instance which the Windows build server then pull from
16:33:32 <jralls> It doesn't any more. It builds from a tarball just like MacOS, and IIUC you've set up flatpak to do the same.
16:34:00 <gjanssens> Heh, right, and that's really even better
16:35:38 <gjanssens> However at least in the flatpak build the repositories continue to play an important role: they are used to determine whether a build is for a tag (=release) or a branch (=nightly) or commit (=nightly)
16:35:59 *** RF has joined #gnucash
16:36:38 <gjanssens> But that does indeed require public accessibility of the tarballs.
16:36:48 <jralls> Here's the problem though: Suppose I don't push the tag and someone pushes to the repo while I'm doing all of the builds and such. When I go to push the release commit and tag I can't. I have to delete the tag, rebase, and start over. Lather, rinse, repeat --> no releases.
16:37:33 <gjanssens> You could separate pushing the release commit from pushing the tag
16:38:22 <gjanssens> Once you push your release commit, any other commits that follow it will be for a future release
16:38:54 <gjanssens> The release tag will be set on that release commit but only pushed once we have a successful release.
16:39:07 <jralls> Heh, most of the time. We've got this mess because it didn't work out that way.
16:39:40 <gjanssens> Right, but let's try to distinguish different aspects of this
16:39:44 <jralls> But it's also true that the 3.8b tag doesn't point at the release commit.
16:40:30 <gjanssens> Which in itself is not a big deal. It's the tag that defines the release. The release commit is just one of the housekeeping tasks preceding it.
16:40:57 <jralls> Right.
16:41:42 <gjanssens> In the strictest sense a release is setting the tag to mark the "golden" commit, generate tarballs from it, write release notes and put all that somewhere online
16:42:26 <gjanssens> The Macos bundle, the Windows installer and the flatpak can also be considered "downstreams", though we do manage them ourselves.
16:42:40 <gjanssens> Their inputs are the release tarballs.
16:43:02 <gjanssens> If they need additional fixes to work correctly, these should be injected as patches.
16:43:25 <gjanssens> That's how downstream packaging works and how I manage the flatpak package as well.
16:44:12 <jralls> OK, though that's not what happened this time. The tarball itself was unbuildable if cmake was < 3.6.
16:44:25 <gjanssens> As we do control these 3 downstream packages, these patches are typically "upstreamed" immediately so the patches typically live only for one release cycle in these package repos.
16:44:33 <jralls> That and cstim's gyrations on the po files.
16:45:12 <jralls> No, the patches would have to stay in the repos forever so that old versions are buildable.
16:45:51 <gjanssens> cstim's gyrations fall in the "internal kitchen" category and could have been dealt with by simply moving the tag before pushing it public
16:46:47 <gjanssens> The other issue would have only been discovered after release (that is after pushing the release tag)
16:48:04 <gjanssens> Going with the "a release is atomic" idea, that would mean we either leave it to downstream to apply a patch (which they could probably pick from our git repo)
16:48:10 <jralls> Probably, because the reporter wouldn't have tried to download the 3.8 tarball if he hadn't seen the tag. In that sense it's a good thing that I pushed the tag early.
16:48:11 <gjanssens> Or start another release.
16:48:23 <gjanssens> A fixup release
16:49:30 *** Han has quit IRC
16:49:58 <jralls> Which is what I would have done if he hadn't caught me while I was still working on the release notes.
16:52:50 *** RF has quit IRC
16:54:15 <gjanssens> It's more formal and more work as things currently stand, because it means redoing the whole process of release commit (with new number), generate tarballs, new release notes,...
16:55:46 <gjanssens> The advantage is that tags, release notes and artefact names use consistent numbering
16:56:02 <jralls> But very short release notes and a one-line addition to NEWS. The rest has to happen regardless.
16:56:19 <gjanssens> Yes, very short release notes.
16:57:07 <gjanssens> I think you being the one doing the releases can best estimate the amount of supplemental work it involves.
16:58:04 <jralls> The only serious extra work is changing all of the gnucash-(guide|help).xmls and regenerating the docs.
16:58:32 <gjanssens> Can we simplify that part ?
16:59:45 <jralls> It should be possible to write a perl script to do it. The changes are all pretty canned.
17:01:03 *** oozer has joined #gnucash
17:01:12 <jralls> The only thing that bugs me about the process is that the Italian and Japanese translations haven't changed in years for want of a translator and it seems bogus to me to claim that they're for 3.8 when they're really for 2.6.4 and 2.4.12 respectively.
17:01:41 <gjanssens> Perhaps we can add a trigger in gitolite to automate as much of the release process as possible that gets triggered when a tag gets set ?
17:02:12 <gjanssens> (That was a general consideration, not for Italian and Japanese)
17:02:42 <jralls> That's what got us into this mess in the first place: We used to push the release tag and pray that the Windows build would work.
17:03:14 <gjanssens> And I suppose that still requires handholding ?
17:04:25 <jralls> Less than before, but it's still a bit of a crap shoot. Manual intervention to recover is much easier now, though.
17:04:56 <gjanssens> Ok.
17:05:19 <gjanssens> We can refine this though.
17:07:06 <jralls> The first thing is to change the policy to "no re-tags". Tag locally, build everything, get the announcement ready, push the tags, push the announcement, send the email.
17:08:16 <gjanssens> Ok
17:09:08 <gjanssens> If we have to re-release due to a bug, what should the next number be then? 3.8a, 3.8.1, 3.9 ?
17:09:49 <gjanssens> And what warants such a new release ? What do we consider important enough ?
17:10:06 *** Mechtilde has quit IRC
17:10:07 <gjanssens> Unable to build on supported architectures would be a good one
17:10:33 <gjanssens> As would be unable to run.
17:11:00 <gjanssens> By the way, do we run distcheck on one of our travis instances ? That should catch missing files, right?
17:11:45 <warlord> jralls, I have power and when I get back should have UPSes.. SO... should be ready to move machines soon. Now it's going to depend on my travel schedule.
17:12:21 <jralls> warlord, OK. I hope it will be before the next release!
17:12:34 <warlord> When is the next release?
17:12:57 <jralls> March 29.
17:13:35 <mdf> jralls: tThanks for fixing up the windows build script. I was out of town all weekend, but I'll give it a go tonight or tomorrow night on a clean VM.
17:13:36 <gncbot> mdf: Sent 2 days, 23 hours, and 37 minutes ago: <jralls> I've finally got webkitgtk fixed up and uploaded and setup_mingw64.ps1 fixed to run pacman -Syu twice and modified to load the webkitgtk3 package from sourceforge.
17:13:39 <jralls> gjanssens, we don't run distcheck on Travis. I'm not sure that we should routinely because it takes so long.
17:14:23 <jralls> mdf: NP, it needed doing. Thanks for troubleshooting it.
17:14:39 <mdf> :)
17:16:04 <gjanssens> jralls: it would have prevented the cmake bug.
17:17:04 <jralls> Had it been run on Ubuntu 14.04, yes.
17:17:19 <gjanssens> Of course, we could also make it procedure to run this on at least two target platforms right before release (and older and newer one)
17:17:21 <warlord> jralls, I am fairly certain it will happen WELL before then. I am fairly confident it will happen in January.
17:17:40 <gjanssens> Then the travis burden wouldn't be necessary.
17:18:29 <gjanssens> Getting late here. Almost time to go to bed.
17:19:38 <jralls> warlord, looking forward to it. I bet you are too.
17:19:51 <warlord> Definitely
17:20:10 <gjanssens> I think a first direction of the future of release management is set. We'll refine as we go along.
17:20:11 <jralls> gjanssens, Maybe we could set up a way to fire off special Travis builds manually.
17:20:30 <gjanssens> Something to investigate
17:20:34 <warlord> Right now I am waiting on some UPS swappage. They sent me an incompatible battery pack. So now they are going to ship me a new (empty) UPS and I'll slip the new batteries into it.
17:20:42 <jralls> Yes. I'll try to distill it into the Release_Process.
17:21:06 <gjanssens> Great. With that I'm leaving.
17:21:11 <gjanssens> See you later!
17:21:22 <jralls> Good night!
17:21:43 <jralls> warlord, Huh? How will a new box fix an incomplete battery pack?
17:22:06 *** gjanssens has quit IRC
17:22:11 <jralls> Oh, *incompatible*. I read "incomplete".
17:24:22 <warlord> The new box will have the correct connection.
17:25:17 <warlord> They sent me new batteries for the UPS and a new external battery pack. The new external battery pack uses a different connector to the main UPS.
17:28:15 *** fell has quit IRC
17:30:51 *** fell has joined #gnucash
17:30:53 *** ChanServ sets mode: +o fell
17:31:53 <jralls> And it's way cheaper to send a new UPS than a new battery pack. Got it.
17:52:23 <warlord> Especially as it's an empty UPS, so yes. And then I'll ship my old UPS back to them.
17:55:15 <warlord> I'll ask them what they want me to do with the old external battery pack
17:56:33 *** nick_ has joined #gnucash
17:59:03 *** nick_ has quit IRC
18:12:52 *** fell has quit IRC
18:22:49 *** Cuare has quit IRC
18:27:02 *** ArtGravity has quit IRC
18:49:12 *** fell has joined #gnucash
18:49:12 *** ChanServ sets mode: +o fell
19:13:50 *** omnireq has quit IRC
19:49:43 *** oozer has quit IRC
20:13:06 *** omnireq has joined #gnucash
20:33:40 *** warlord has quit IRC
20:34:40 *** guak has quit IRC
20:40:29 *** jonp` has quit IRC
21:09:07 *** Gerd has quit IRC
21:13:35 *** boldstripe has quit IRC
21:14:34 *** boldstripe has joined #gnucash
21:22:40 *** phebus has joined #gnucash
21:22:40 *** ChanServ sets mode: +v phebus
21:44:17 *** bertbob has quit IRC
21:47:05 *** fell has quit IRC
21:48:40 *** bertbob has joined #gnucash
21:48:42 *** ChanServ sets mode: +v bertbob
21:50:00 *** omnireq has quit IRC
21:53:39 *** omnireq has joined #gnucash
21:55:18 *** bertbob has quit IRC
22:00:56 *** bertbob has joined #gnucash
22:00:59 *** ChanServ sets mode: +v bertbob
22:09:15 *** jervin has joined #gnucash
22:31:48 *** jervin has quit IRC
22:57:45 *** jervin has joined #gnucash
23:13:34 *** boldstripe has quit IRC
23:14:30 *** boldstripe has joined #gnucash
23:23:23 *** jervin has quit IRC
23:48:51 *** omnireq_ has joined #gnucash
23:50:03 *** omnireq has quit IRC