Time  Nick       Message
12:52 rubenwardy @grorp: #13807 is ready if you'd like to take another look
12:52 ShadowBot  https://github.com/minetest/minetest/issues/13807 -- Add package update detection on Content tab by rubenwardy
13:27 grorp      rubenwardy: thank you, I've left a review
13:48 rubenwardy grorp: updaed
13:49 rubenwardy also fixed another bug with autoinstall
15:52 json       https://github.com/minetest/minetest/pull/13906
15:52 json       what changes are required?
15:54 rubenwardy See last comment
15:57 json       he is simply saying that change is needed. Which ones exactly I still don’t understand
15:59 json       hello!
15:59 json       https://github.com/minetest/minetest/pull/13906 - Offer ContentDB updates for leftover bundled Minetest Game
16:00 json       what changes are required?
16:05 MTDiscord  <warr1024> It seems like it would have been smart to have included a release number in the bundle as soon as MTG became available on CDB, regardless of when we were going to eventually get to where we are now with the debundling...
16:05 MTDiscord  <warr1024> It does kind of make me wonder if we should look for a .git dir and not update MTG from CDB if it has one of those, and then we can assume everything else is updatable.
16:06 grorp      that's about what my pr does
16:06 MTDiscord  <warr1024> oh, I misread it, yeah, that's an extra check, not an implied assumption, it seems.
16:08 MTDiscord  <warr1024> I'd kinda like to see this applied to just everything and not just MTG, but when I think of scenarios where it could go wrong, they seem both pathological and, sadly, pretty likely.
16:09 MTDiscord  <warr1024> Like a dev who is not using any version control, just uploads zips to CDB, and gets their pending work blown away because of a bad "update all" button click.  On the one hand they honestly probably deserve what they get, but on the other hand, I'd hate to have to deal with the consequences anyway...
16:13 celeron55  it could work so that minetest would decline to update things from contentdb that weren't originally downloaded by minetest from contentdb. that would of course cause a lot of inconvenience in some situations
16:14 celeron55  (i guess it could ask whether the user is totally sure about it)
16:15 rubenwardy that's the current state - things installed outside of CDB won't by updated by CDB
16:15 rubenwardy the problem we're trying to solve here is moving MTG to a CDB install
16:15 rubenwardy this should only apply to MTG and not other games
16:15 erle       yeah please nothing else, i have my own mods symlinked into minetest mods directory
16:15 MTDiscord  <warr1024> The problem here is that we have something in a state it shouldn't be able to be in: something that's supposed to be maintained by MT/CDB but isn't marked as such due to baggage reasons.
16:16 erle       Warr1024 i have already suggested that minetest_game could come with a hardcoded marker for one or two releases, would that *not* solve it?
16:19 grorp      that would work, but if you can solve the same problem in less time, why not?
16:20 rubenwardy that would require delaying debundling to 5.9.0, and wouldn't work for those that skip updates
16:21 celeron55  ah yes of course
16:21 rubenwardy merging #13807 in 10
16:21 ShadowBot  https://github.com/minetest/minetest/issues/13807 -- Add package update detection on Content tab by rubenwardy
16:21 rubenwardy (we agreed to merge 3 PRs and extend the freeze)
16:21 celeron55  the extreme quick solution would be to hash the minetest_game files and check that the hashes match a known previous release version
16:22 MTDiscord  <warr1024> Yeah, erle, I agree with your suggestion but we don't have the time machine it would require to implement it properly now, and I'm also against delaying the debundling ... where we're at right now we probably should have been a couple years ago as it is...
16:22 erle       well that's just a stratetic question of “are the consequences worth it?”
16:23 MTDiscord  <warr1024> Having to have MTE have memorized hashes of past MTG versions seems sort of counterproductive in its own way.  It would be ironic if we have to bake more MTG legacy into MTE to be able to free MTE from MTG legacy.
16:23 erle       by the way, often when i do not say “do not do the thing” but just point out issues with a proposal what i want to convey is “consider if it is worth it”. i am indifferent to debundling mtg in general, but i think it is overall a good thing.
16:23 erle       like i am indifferent to the speed of how it happens
16:23 erle       didn't happen in years, so why the rush hehe
16:24 celeron55  Warr1024: it would be just for a transition period of course
16:24 celeron55  like, until 6.0 or whatever
16:24 grorp      re hashing: who hasn't changed a line or two in their minetest_game installation? :P
16:24 erle       hehe what grorp says
16:24 erle       also the maintenance input of a bunch of hashes is about zero
16:25 erle       i.e. not all old code fulfils the ”deleted code is debugged code” stereotype
16:25 celeron55  well if you assume many users have changed some lines but still want to update, then checking hashes is useless
16:25 erle       i think if you changed, it is proper to assume you do not want it overwritten (and also maybe you know what you are doing)
16:25 celeron55  maybe it should just copy the installed minetest_game to a backup directory
16:25 celeron55  and replace it with the cdb version in its place
16:26 celeron55  that would avoid data loss in a very simple way
16:26 erle       that's what a lot of software actually does yeah
16:26 celeron55  the only minus is it would use up some more disk space, but minetest_game isn't that big
16:28 MTDiscord  <warr1024> I do rather like the idea of a backup copy, yeah.
16:29 rubenwardy it's only 5MB
16:29 rubenwardy so makes sense
16:30 celeron55  (we of course don't know how big the user's minetest_game is, but the bigger it is, the more important it probably is)
16:30 rubenwardy yeah just going with the average case here
16:31 erle       for destructive updates, “going with the average case“ (average on what evidence?) is not necessarily the best default though
16:31 erle       so is there anything against backup copy?
16:31 erle       despite size (which celeron55 correctly remarks means a backup is more important)
16:31 celeron55  well it can be for sure said disk space usage will increase by 5MB or whatever minetest_game's size is on cdb
16:31 MTDiscord  <warr1024> it does sort of suggest that rather than making a backup "copy" you could just rename the existing one to like minetest_legacy_game or something...
16:32 erle       oh yes
16:32 celeron55  yes, move (or rename) is better
16:32 erle       rename it, edit the description
16:32 celeron55  of course that doesn't move the worlds onto the renamed game
16:33 erle       well hmm
16:33 MTDiscord  <warr1024> the drawback to renames is what do you do with their existing worlds?  do you relink them to the renamed game, so they work consistently, but will never be able to get updates?  Or do you leave them linked to the old game but now they need to get updates from CDB before they can play it?
16:33 celeron55  that's why i suggested maybe a backup dir is better
16:33 rubenwardy I'd backup rather than rename
16:33 grorp      +1
16:33 MTDiscord  <warr1024> I suppose it depends on whether we would automatically install MTG from CDB for users who had legacy MTG installed before, or whether we'd decouple those actions so that users might have to do it themselves (i.e. so that you couldn't end up in weird failed states where the rename completed but the install failed)
16:33 erle       chaotic evil idea: rename the minetest game on cdb, all hell breaks loose
16:34 MTDiscord  <warr1024> renaming MTG would be chaotic good
16:34 celeron55  that would create some kind of an insane dependency hell
16:35 erle       rename it to minetest_gane to make it harder to detect visually
16:37 ROllerozxa heh... minetest still has some compatibility code to migrate worlds with the 'mesetint' gameid to 'minetest'
16:39 erle       ROllerozxa “team meetings” is an anagram of “minetest game” and therefore an excellent new name!
16:43 MTDiscord  <warr1024> Seems like the ideal name for a design-by-committee game...
17:26 [MTMatrix] <localhost> meeting in minetest world
20:27 grorp      Thinking about it: I'm not sure if a backup is at all needed. After all, every Minetest update before 5.8.0 also overwrote Minetest Game, wiping any  modifications made by the user.
20:37 erle       grorp it did not delete existing files in that folder though?
20:38 erle       like if you have placed some textures or mods there (i admit i have)
20:38 MTDiscord  <warr1024> That's fair but do we need to worry about the potential case of people who have learned to be careful and specifically exclude that from overwrites, only to be surprised by THIS time it working a different way than they expected?
20:38 erle       by the way, MESA has a much better bug report template than minetest
20:39 MTDiscord  <warr1024> Are we planning on deleting it, or are we planning on just injecting a release key into the mod.conf so that CDB can update it...?
20:39 erle       in particular they just start with ”post the result of this command: inxi -GSC -xx”
20:40 erle       and then for the manual fill-in they post the commands that might work to figure it out
20:40 erle       but the inxi thing is awesome
20:44 grorp      Warr1024: #13906 could be described as simulating the existence of a release key in game.conf, so that CDB can update it
20:44 ShadowBot  https://github.com/minetest/minetest/issues/13906 -- Offer ContentDB updates for leftover bundled Minetest Game by grorp
20:45 grorp      but if the user actually choses to update via CDB, the package will be fully deleted first (that's the case with all CDB updates)
20:45 MTDiscord  <warr1024> So if we're not really outright deleting MTG any more than any other update would, this doesn't seem to be much of a problem to me.
20:45 MTDiscord  <warr1024> I mean, if there's a risk we worry about people modifying things locally and then losing their changes, MTG is just a specific instance of a general case then.
20:46 erle       uh
20:46 MTDiscord  <warr1024> I suppose in theory we could hash the entire mod in some canonical order and persist and compare some hash in the conf file, but that's a hell of a todo.
20:46 erle       the backup copy thing is the simplest thing that works
20:46 MTDiscord  <warr1024> yeah, that's fine for this specific case
20:47 erle       for other things, cdb should never update whatever i have symlinked into that folder or my dev folders are going to be blown away?
20:48 MTDiscord  <warr1024> I would like to think we could do a thing like asking the user "it looks like you fucked with XYZ locally, local changes will be lost; proceed?" or something.  No idea how much of a pain in the ass that could be to make happen, though, nor whether it's actually good UX.
20:48 MTDiscord  <warr1024> I mean, maybe the thing to do is just always proceed and always make the backup copy automatically if we detect local changes.
20:50 erle       well my local copy will not have a version number
20:50 erle       so i hope cdb leaves it alone right?
20:51 MTDiscord  <warr1024> For non-MTG things?  Sure, yeah, if you're modifying a copy you installed yourself, and not just messing around with something you got from CDB.
21:01 erle       i am modifying mostly copies i have *written* myself ;)
22:28 Desour     merging #13940 and #13941 in 5
22:28 ShadowBot  https://github.com/minetest/minetest/issues/13940 -- Sounds: Don't pause new sounds when paused by Desour
22:28 ShadowBot  https://github.com/minetest/minetest/issues/13941 -- [NOSQUASH] Sounds: Fix some fade-related bugs by Desour