WEBVTT 00:00.000 --> 00:16.000 Okay. Hello, everyone. Thanks for coming. Thanks for having me. So my name is David Petera. 00:16.000 --> 00:23.000 And I will talk about the process of buggy reporting today. So quick words about me. 00:24.000 --> 00:29.000 I study software engineering at Faculty of Maths and Physics at Prague. 00:29.000 --> 00:35.000 And I do support and testing in the birth internet that I think demon in, 00:35.000 --> 00:45.000 see that make, let me find the scene. So we have all been there. 00:45.000 --> 00:49.000 We worked tirelessly on a new version of software, adding new features, 00:49.000 --> 00:56.000 making things faster, making things better. We are on our tests. Everything is green. We hit release. 00:56.000 --> 01:03.000 Finally, we can rest for a bit. But then, our mailbox looks something like this. 01:03.000 --> 01:10.000 Correct reports. So yeah, we may not like it, especially in this bedroom. 01:10.000 --> 01:18.000 But we try to stop it as much as possible. With our choice of run times, automatic testing and 01:18.000 --> 01:24.000 like other elaborate infrastructure. But it is inevitable, basically. 01:24.000 --> 01:29.000 So, when it does happen, we need to get information about the crash. 01:29.000 --> 01:34.000 We need to get information, crucially about the crash from the users themselves. 01:34.000 --> 01:38.000 And it can be quite a messy process. 01:38.000 --> 01:46.000 It can look something like this. Basically, a bird or any other like program running directly on 01:46.000 --> 01:49.000 the system when they crash, they generate a corfile. 01:49.000 --> 01:55.000 So, users tend to send us corfile and the configuration of bird. 01:55.000 --> 02:01.000 Which, as you might know, like without the exact binary, which it was running, 02:01.000 --> 02:06.000 is not really that useful. So we have to ask for the binary. 02:06.000 --> 02:11.000 Then, they send us the corfile, the config, the binary. 02:11.000 --> 02:17.000 And that works most of the time. But sometimes, we need information about, like additional information about 02:17.000 --> 02:24.000 the system, like distribution, kernel version, and stuff like that. So, we have to ask for that. 02:24.000 --> 02:31.000 So, we get corfile, config, binary info, system info, or sorry, binary. 02:31.000 --> 02:38.000 And system info, but sometimes, bird crashes inside one of the dependencies. 02:38.000 --> 02:43.000 We need the dependencies as well. If we have different versions, we basically like in GDP. 02:43.000 --> 02:51.000 We don't see the stack frames clearly, and we need the binaries of the libraries as well. 02:51.000 --> 03:00.000 So, then, we have to ask again, sometimes, when we get the corfile config binary system info, dependencies. 03:00.000 --> 03:06.000 And that works most of the time. But, if the dependencies don't have the debux symbols, 03:06.000 --> 03:11.000 we have to get them manually, or use utilities, like debux info, D to find them. 03:11.000 --> 03:19.000 So, all of this, finally, we have everything, the corfile config binary system info, dependencies, debux symbols, 03:19.000 --> 03:25.000 and we can start debugging. But, all of this waste a lot of time potentially, this can be like, 03:25.000 --> 03:34.000 worth of emails and can be kind of a hell. So, what to do with it? What is the solution? 03:34.000 --> 03:41.000 Sorry, that's not what I wanted. 03:41.000 --> 03:49.000 So, let's reiterate what kind of, we need from a tool or something to solve our problem. 03:49.000 --> 04:00.000 We would ideally need to automate the process. So, like, yeah, we don't have to do this manually again. 04:00.000 --> 04:08.000 We would ideally ask, sorry, let me just check if, yeah, yeah. 04:08.000 --> 04:16.000 We would ideally just, like, tell the users, one command, run this with this, like, run that, 04:16.000 --> 04:23.000 and it will just bundle everything that we need for the debugging. 04:23.000 --> 04:35.000 Also, we need for the tool to work on, like, the variety of systems, and ideally, of course, it should be open source. 04:36.000 --> 04:46.000 So, we were asking ourselves, like, are we alone in this? Of course, like, other developers have the same issue. 04:46.000 --> 05:03.000 But, we tried to look at existing solutions, like, abort, system decode dump, or, like, abort, which, like, work, but they have to be running at the, like, time that program crashes. 05:03.000 --> 05:13.000 And also, they are, kind of, like, system-specific, like, the system-d1, and appartists for, you want to, so, we decided to make our own tool. 05:13.000 --> 05:22.000 The tool is called the Backpack, and, let me try to, like, say, tell you what it is really. 05:22.000 --> 05:31.000 So, it is a command line tool, written first in Bash, but quickly, that was, it was written to Python for obvious reasons. 05:32.000 --> 05:38.000 The Python version is 3.6, which is quite old. 05:38.000 --> 05:49.000 It is quite old deliberately, because some of our customers may or may not be running end-of-life systems, like, eight years old, or something, without support. 05:49.000 --> 06:00.000 But, the 3.6 should be, like, should be a quite good for that. 06:00.000 --> 06:05.000 It also has minimal dependencies to work. 06:05.000 --> 06:15.000 It just needs, like, for now, to utilize the LED, for getting the dynamic little inc libraries, but this will be removed also, quite soon. 06:15.000 --> 06:20.000 Yeah, and it's developed under GPLV-free. 06:20.000 --> 06:32.000 From the user point of view, you basically call one command, which is the Backpack Pack. 06:32.000 --> 06:36.000 You provide a core file, optionally the binary. 06:36.000 --> 06:42.000 The Backpack can detect the binary from the core file if it's possible. 06:42.000 --> 06:44.000 It works most of the time. 06:44.000 --> 06:56.000 The reflect is there just to, like, see what is being done by the program and what is copied and to see a cute picture of a cat. 06:56.000 --> 07:06.000 Yeah, and if the user wants to provide additional files like configurations and anything that would help the developers, it can do so. 07:06.000 --> 07:24.000 This, basically, when a user runs this command, the Backpack will create, like, tar archive and bundle everything, like, together, the information, like the core pack, the, sorry, the core file, the binary. 07:24.000 --> 07:34.000 Everything, basically, that is needed, the system info, the libraries in the structure, the, in the direct, direct structure that it was on the system, 07:34.000 --> 07:38.000 which then can be later used in GDP. 07:38.000 --> 07:46.000 So, from just to show how, like, the structure of the tar archive, it's quite simple. 07:46.000 --> 07:54.000 If I'm able to move, yeah, basically, like I said, we have some, like, config JSON, but for the most part, it's, like, just what I said. 07:54.000 --> 08:04.000 The system in a system info that we safe is just the profiles, the main ones that are usable, and yeah, that's the additional files. 08:04.000 --> 08:12.000 The advantage of this is that it's like any other tar ball, which can just be examined manually if needed. 08:12.000 --> 08:16.000 Yeah, yeah, this is the cat. 08:16.000 --> 08:28.000 If, if you run this, and it should be, it's smaller, but basically you see that it copies all the libraries, then the, the stuff, 08:28.000 --> 08:36.000 and just tells you where, where it's, where it, that it, like, copied to. 08:36.000 --> 08:43.000 So, now from the developer point of view, it, you have, like, two main commands. 08:43.000 --> 08:57.000 One is debug, which, just, you know, if you, if you use the bindels, this, this tar archive sends it to the developer, then the developer will use it in this process. 08:57.000 --> 09:02.000 And basically, this command will open GDP for you. 09:02.000 --> 09:16.000 It sets everything up like the sisterhood with the, it will download the bug info, the bug symbols, and run GDP, and you can basically start the bugging right away. 09:16.000 --> 09:25.000 The browser command is there just to examine the system info and additional files. 09:25.000 --> 09:30.000 So, the benefits of this is that there is no backend forward. 09:30.000 --> 09:38.000 The developer has all the information they need right away at all times. 09:38.000 --> 09:50.000 Also, if you, like, manage to convince your users to use this tool, the bug reporting can be, like, normalized, it's always the same. 09:50.000 --> 09:58.000 The user don't have to think about, like, what information should I provide, it will just be in the bundle. 09:58.000 --> 10:05.000 So, overall, like, better experience for users and deaths also. 10:05.000 --> 10:12.000 Some future work, this setup was mainly used for, like, in house purposes for us. 10:12.000 --> 10:15.000 We managed to publish it because why not. 10:15.000 --> 10:27.000 But I can imagine that, like, other developers have their specific needs that what they need from the bugging tool or, like, reporting tool. 10:27.000 --> 10:39.000 And so, it would be nice to support, like, plugins or other, like, modifications to the code, without, you know, like, rewriting the whole software. 10:39.000 --> 10:43.000 It would be also cool if we have the system info. 10:43.000 --> 10:51.000 We can possibly, like, spin up, like, Docker container or something like that that would have the user system on it. 10:51.000 --> 11:00.000 And we can, for example, like, replicate the crash or the bug or debug it directly in the container. 11:00.000 --> 11:10.000 Yeah, if, if it is, like, needed, it could also be changed to a demon bundle. 11:10.000 --> 11:14.000 Yeah, if you have any ideas, let me know. 11:14.000 --> 11:17.000 It would be nice to collaborate. 11:17.000 --> 11:24.000 So, that's basically it for my presentation. 11:24.000 --> 11:28.000 Do you have a couple more minutes you can think of questions if you want? 11:28.000 --> 11:32.000 Okay, does anybody have questions or such as questions? 11:32.000 --> 11:33.000 Yes. 11:33.000 --> 11:35.000 So, you are dependent on white command type. 11:35.000 --> 11:37.000 So, yes. 11:37.000 --> 11:40.000 Do you consider this as a robot-like indentations? 11:40.000 --> 11:43.000 Like, you just must have the title. 11:43.000 --> 11:44.000 Okay. 11:44.000 --> 11:51.000 I will try to repeat the question that we depend on the Python runtime that is true. 11:51.000 --> 12:02.000 Yeah, I don't, like, we would need to kind of, like, have the, have it as a binary, which is possible. 12:02.000 --> 12:07.000 But, I don't see it as a big limitation. 12:07.000 --> 12:18.000 Like, I think people using our software also have Python runtime on their systems. 12:18.000 --> 12:22.000 Any other questions? 12:22.000 --> 12:26.000 So, you can see the QR code that's the good-lop page. 12:26.000 --> 12:32.000 And, you can meet us at the Birdstand in the Q-Building. 12:32.000 --> 12:42.000 Thank you.