| Time |
Nick |
Message |
| 01:21 |
|
tekakutli joined #minetest-dev |
| 01:56 |
|
v-rob joined #minetest-dev |
| 02:25 |
|
v-rob joined #minetest-dev |
| 02:29 |
|
queria joined #minetest-dev |
| 02:33 |
|
queria joined #minetest-dev |
| 03:08 |
|
Extex joined #minetest-dev |
| 03:36 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:39 |
|
v-rob joined #minetest-dev |
| 06:51 |
|
v-rob joined #minetest-dev |
| 07:23 |
|
tekakutli joined #minetest-dev |
| 07:30 |
|
specing joined #minetest-dev |
| 07:30 |
|
ssieb joined #minetest-dev |
| 07:30 |
|
Krock joined #minetest-dev |
| 07:30 |
|
clavi joined #minetest-dev |
| 07:30 |
|
celeron55 joined #minetest-dev |
| 07:32 |
|
tekakutli joined #minetest-dev |
| 08:05 |
|
hendursa1 joined #minetest-dev |
| 08:32 |
MTDiscord |
<luatic> I'm not a fan of "send automatically". I know of some applications sending sensitive data in their bug reports. Minetest shouldn't join them. Currently there is a single global log which contains all kind of information (often including chat logs). It should be up to the user to include only necessary log information. |
| 08:43 |
|
cx384 joined #minetest-dev |
| 08:45 |
|
queria joined #minetest-dev |
| 09:13 |
|
Fixer joined #minetest-dev |
| 09:25 |
|
specing joined #minetest-dev |
| 10:02 |
celeron55 |
there's also the problem of who hosts the data, and who gets to see the data |
| 10:33 |
|
tekakutli joined #minetest-dev |
| 10:42 |
|
calcul0n joined #minetest-dev |
| 10:50 |
|
pmp-p joined #minetest-dev |
| 13:16 |
|
erlehmann joined #minetest-dev |
| 14:24 |
|
calcul0n_ joined #minetest-dev |
| 14:29 |
rubenwardy |
I use Sentry for automatic error reporting, but I added it early on so I know that nothing personal is logged |
| 14:29 |
rubenwardy |
Sentry contains tools for censoring info, so you could use that to remove IP addresses and chat messages |
| 14:30 |
rubenwardy |
A lot of crashes will probably be things like segfaults, you can't be sure whether any particular memory contains personal info in that case |
| 14:50 |
|
Fixer joined #minetest-dev |
| 15:11 |
|
flux__ joined #minetest-dev |
| 15:52 |
|
Extex joined #minetest-dev |
| 17:28 |
|
hendursaga joined #minetest-dev |
| 17:39 |
|
v-rob joined #minetest-dev |
| 17:42 |
erlehmann |
sentry is really useful, but the vast majority of bugs i saw in sentry was in code that was not covered by tests |
| 17:42 |
erlehmann |
besides data collection is a legal nightmare |
| 17:58 |
|
Lone_Wolf joined #minetest-dev |
| 18:07 |
celeron55 |
you have to state next to the "send bug report" button what data is sent, where it is stored, how long it is stored and who is going to see it |
| 18:07 |
celeron55 |
i don't think any country disallows it when it's done like that |
| 18:08 |
celeron55 |
of course if you then do mistakes and something happens that was not said to happen, then it's an issue |
| 18:08 |
celeron55 |
(i.e. data leak) |
| 18:08 |
celeron55 |
and you get in the news and are laughed at |
| 18:09 |
celeron55 |
a good compromise could be a text field with the report, and a text stating "if you need help, copy this and show it to a project maintainer" |
| 18:11 |
celeron55 |
then what happens with the data is up to the user, and the user can choose what messaging systems they trust, and can search and censor the data by themselves as they like |
| 18:11 |
celeron55 |
it kind of already happens with our Lua error dialog |
| 18:15 |
celeron55 |
it shows the error message, line number, the file with path, and the path generally contains the game and mod name and often even the minetest version, and the traceback |
| 18:15 |
celeron55 |
in a copyable text box |
| 18:17 |
celeron55 |
or screenshottable |
| 18:17 |
celeron55 |
to improve it, maybe a log excerpt could be added, and maybe the engine could attempt to show it even for C++ crashes (it's often possible, altough sometimes it only causes an even more confusing crash) |
| 18:46 |
Krock |
sfan5: regarding #11678: do you know whether only large packets are affected? the report repeats seqnums in range [65503, 65531] which indicates a large packet |
| 18:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/11678 -- Can not play(or host) game on Android 8&10 for latest master. |
| 18:46 |
sfan5 |
it affects everything |
| 18:46 |
sfan5 |
also uh seqnums do not correlate with packet size |
| 18:46 |
Krock |
there was also a little behaviour change regarding the timeout-reset which was newly introduced |
| 18:47 |
Krock |
for reliable packets, there's usually multiple sequntial seqnums |
| 18:47 |
Krock |
hence I assumed those would belong together (all channel 1 as well) |
| 18:47 |
sfan5 |
ah, could be |
| 18:49 |
Krock |
or there might be timeout on client-side for reliable packets that didn't all arrive in time. previously, timed out packets would be re-sent basically instantly |
| 18:50 |
Krock |
whereas the time is now reset after every timeout |
| 18:53 |
sfan5 |
I don't know what you are referring to |
| 18:55 |
Krock |
nvm. invalid idea. |
| 19:29 |
|
tekakutli joined #minetest-dev |
| 19:54 |
|
beanzilla joined #minetest-dev |
| 19:55 |
|
beanzilla joined #minetest-dev |
| 20:15 |
|
v-rob joined #minetest-dev |
| 20:27 |
|
beanzilla joined #minetest-dev |
| 21:07 |
|
v-rob joined #minetest-dev |
| 21:08 |
|
olliy joined #minetest-dev |
| 21:24 |
|
specing_ joined #minetest-dev |
| 23:24 |
|
AliasAlreadyTake joined #minetest-dev |
