| Time |
Nick |
Message |
| 00:30 |
|
TheCoffeMaker joined #minetest-dev |
| 00:36 |
|
TheCoffeMaker joined #minetest-dev |
| 00:42 |
|
ShadowBot joined #minetest-dev |
| 00:52 |
|
v-rob joined #minetest-dev |
| 02:39 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:37 |
|
calcul0n_ joined #minetest-dev |
| 09:38 |
|
calcul0n joined #minetest-dev |
| 10:31 |
|
erle joined #minetest-dev |
| 11:07 |
|
calcul0n_ joined #minetest-dev |
| 12:27 |
|
calcul0n_ joined #minetest-dev |
| 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 joined #minetest-dev |
| 13:27 |
grorp |
rubenwardy: thank you, I've left a review |
| 13:33 |
|
vampirefrog joined #minetest-dev |
| 13:35 |
|
Desour joined #minetest-dev |
| 13:48 |
rubenwardy |
grorp: updaed |
| 13:49 |
rubenwardy |
also fixed another bug with autoinstall |
| 14:07 |
|
Noisytoot joined #minetest-dev |
| 14:20 |
|
appguru joined #minetest-dev |
| 15:03 |
|
Noisytoot joined #minetest-dev |
| 15:50 |
|
json joined #minetest-dev |
| 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:58 |
|
grorp joined #minetest-dev |
| 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:00 |
|
olliy1or joined #minetest-dev |
| 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 |
|
grorp joined #minetest-dev |
| 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... |
| 16:46 |
|
Noisytoot joined #minetest-dev |
| 16:52 |
|
grorp joined #minetest-dev |
| 17:01 |
|
Noisytoot joined #minetest-dev |
| 17:09 |
|
Noisytoot joined #minetest-dev |
| 17:26 |
[MTMatrix] |
<localhost> meeting in minetest world |
| 17:37 |
|
calcul0n_ joined #minetest-dev |
| 18:03 |
|
appguru joined #minetest-dev |
| 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:43 |
|
grorp joined #minetest-dev |
| 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. |
| 20:57 |
|
grorp left #minetest-dev |
| 21:01 |
erle |
i am modifying mostly copies i have *written* myself ;) |
| 21:06 |
|
Desour joined #minetest-dev |
| 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 |
| 22:33 |
|
panwolfram joined #minetest-dev |
