11 Dec
2020
11 Dec
'20
3:23 a.m.
Hi all,
the eighth service on the list of services to migrate is Crash report
storage.
-- Migration status --
While for previous services here I could bring positive information, now
it's time for a service that is very sad.
Because this service resides on old primary server, it requires migration.
Unfortunately, we do not currently have any information about this
service - nor the source code for server side. Therefore in the current
state of service, we can not ensure the issuance of a new ssl certificate.
For everything, we must be able to contact Tim.
Other problems are that the web interface is unfinished, making it
difficult to use. It is not possible to mark a records as completed. At
the same time, retrieving the list is often not complete, so there is an
increased effort required to obtain the latest records. Many records are
generated without the presence of debug symbols, so their usefulness is
reduced.
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records
so that we can migrate the service and then work on improving it. Or we
could implement the server side of the service from scratch, based on the
client side code in tdelibs. Or we can look for a similar service with a
GPL license and the ability to install on our server. In any case, it will
probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source
solutions that could serve our purpose?
Cheers
--
Slávek
11 Dec
11 Dec
1:33 p.m.
On Fri, 11 Dec 2020 04:23:50 +0100
Slávek Banko via tde-users <users(a)trinitydesktop.org> wrote:
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records
so that we can migrate the service and then work on improving it. Or we
could implement the server side of the service from scratch, based on the
client side code in tdelibs. Or we can look for a similar service with a
GPL license and the ability to install on our server. In any case, it will
probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source
solutions that could serve our purpose?
Only thing I can think of is, does the server-side code from the KDE era
still exist in their source control somewhere? If the client side hasn't
changed very much, it might provide a place to start in recreating the
server.
E. Liddell
1:40 p.m.
On Friday 11 of December 2020 14:33:47 E. Liddell wrote:
On Fri, 11 Dec 2020 04:23:50 +0100
Slávek Banko via tde-users <users(a)trinitydesktop.org> wrote:
If memory serves me right, zploading crash reports and the corresponding
server side is a new code from Tim. As far as I know, there was no similar
solution at the time of KDE. In any case, thank you for a good idea.
Cheers
--
Slávek
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing
records so that we can migrate the service and then work on improving
it. Or we could implement the server side of the service from scratch,
based on the client side code in tdelibs. Or we can look for a similar
service with a GPL license and the ability to install on our server.
In any case, it will probably take a lot of effort here to make the
service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open
source solutions that could serve our purpose?
Only thing I can think of is, does the server-side code from the KDE era
still exist in their source control somewhere? If the client side
hasn't changed very much, it might provide a place to start in
recreating the server.
E. Liddell
____________________________________________________ 
3:02 p.m.
On 2020/12/11 10:40 PM, Slávek Banko via tde-users wrote:
If memory serves me right, zploading crash reports and
the corresponding
server side is a new code from Tim. As far as I know, there was no similar
solution at the time of KDE. In any case, thank you for a good idea.
Yes, that was something added by Tim in 2013/2014. If you look in ML archive, you can
surely find an email about it.
Cheers
Michele
3:27 p.m.
On Friday 11 of December 2020 16:02:00 Michele Calgaro via tde-users wrote:
On 2020/12/11 10:40 PM, Slávek Banko via tde-users
wrote:
Michele, good point:
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesk…
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
Cheers
--
Slávek
If memory serves me right, zploading crash
reports and the
corresponding server side is a new code from Tim. As far as I know,
there was no similar solution at the time of KDE. In any case, thank
you for a good idea.
Yes, that was something added by Tim in 2013/2014. If you look in ML
archive, you can surely find an email about it. Cheers
Michele
3 p.m.
-- What needs to be done --
We have to decide what to do next with this service.
We will either need to obtain the source code and data of existing records
so that we can migrate the service and then work on improving it. Or we
could implement the server side of the service from scratch, based on the
client side code in tdelibs. Or we can look for a similar service with a
GPL license and the ability to install on our server. In any case, it will
probably take a lot of effort here to make the service useful.
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open source
solutions that could serve our purpose?
Hi Slavek,
given that lot of crash reports are already quite old and that it is always difficult to
reach Tim, it probably makes
more sense to create a new service on the new tde-box and start from scratch, preparing
something more user friendly
than the original service.
If there is an open source software that could do the job already, even better.
Cheers
Michele
4:10 p.m.
On Thu December 10 2020 19:23:50 Slávek Banko via tde-users wrote:
Because this service resides on old primary server, it
requires migration.
Unfortunately, we do not currently have any information about this
service - nor the source code for server side. Therefore in the current
state of service, we can not ensure the issuance of a new ssl certificate.
For everything, we must be able to contact Tim.
Are crash dumps just text or is there more to them? If text you could
at least in the short term just change the client side to mail them to
a private mailbox accessible only to trusted devs.
--Mike
12 Dec
12 Dec
1:58 a.m.
On Friday 11 of December 2020 17:10:22 Mike Bird via tde-users wrote:
On Thu December 10 2020 19:23:50 Slávek Banko via
tde-users wrote:
The data is prepared as a text file and sent as multipart/form-data.
https://mirror.git.trinitydesktop.org/cgit/tdebase/tree/drkonqi/toplevel.cp…
Here it will probably be useful to divide the solution into two phases:
1. Prepare a reverse proxy configuration for the crash report service in
the web server on the tde-box and try to contact Tim to change the address
in the DNS record so that the communication for crash report service is
directed to the tde-box.
In this first phase, requests would be forwarded to the old primary server
as they are now. However, on the web server side of the tde-box we would
deal with issuing certificates.
2. Prepare a new backend for this service. And once we have a replacement
ready for this service, we will be able to easily switch it by changing
the settings of our reverse proxy on tde-box.
Cheers
--
Slávek
Because this service resides on old primary
server, it requires
migration. Unfortunately, we do not currently have any information
about this service - nor the source code for server side. Therefore in
the current state of service, we can not ensure the issuance of a new
ssl certificate. For everything, we must be able to contact Tim.
Are crash dumps just text or is there more to them? If text you could
at least in the short term just change the client side to mail them to
a private mailbox accessible only to trusted devs.
--Mike
____________________________________________________
9:51 a.m.
On 2020/12/12 10:58 AM, Slávek Banko via tde-users wrote:
1. Prepare a reverse proxy configuration for the crash
report service in
the web server on the tde-box and try to contact Tim to change the address
in the DNS record so that the communication for crash report service is
directed to the tde-box.
In this first phase, requests would be forwarded to the old primary server
as they are now. However, on the web server side of the tde-box we would
deal with issuing certificates.
2. Prepare a new backend for this service. And once we have a replacement
ready for this service, we will be able to easily switch it by changing
the settings of our reverse proxy on tde-box.
Sounds like a good plan to me :-)
Cheers
Michele
7:20 p.m.
On Friday 11 of December 2020 04:23:50 Slávek Banko via tde-users wrote:
-- More ideas and suggestions?
Do you have any other ideas and suggestions? Do you know of any open
source solutions that could serve our purpose?
When I tried to find a suitable existing solution that would suit our
needs, I only found Sentry suitable. It looks like a very sophisticated
system, but on the other hand it seems too big:
https://sentry.io/
As I thought more about it, I had the idea that we could try to integrate
the backend for dr-konqi on the server so that crash-reports could be
created as Issues in TGW. What is your opinion on this idea?
Cheers
--
Slávek
11:19 p.m.
Slávek Banko via tde-users wrote:
I thought more about it, I had the idea that we could
try to integrate
the backend for dr-konqi on the server so that crash-reports could be
created as Issues in TGW. What is your opinion on this idea?
May be it is worth trying. But some system issues that cause crashes are not
exactly caused by issue in TDE. But you can try and see how it works
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net
Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
13 Dec
13 Dec
12:17 a.m.
On Sunday 13 of December 2020 00:19:01 deloptes via tde-users wrote:
Slávek Banko via tde-users wrote:
Dr. Konqi only responds if a TDE application crashes. Therefore, only
backtraces for TDE applications should be uploaded there.
For cases where the crash is caused by another library, it will be useful
to verify whether it is a bug in the relevant library or whether it is a
library call issue that should be addressed in a TDE application. For such
cases, it will be correct that the backtrace is uploaded for the
respective TDE application.
The only somewhat confusing situation can be when it comes to a GTK
application that runs with the TQt style => as a TDE application. However,
even such cases will be good if we have the backtrace recorded.
That's why I expect it to be good for all cases.
Cheers
--
Slávek
I thought more about it, I had the idea that we
could try to integrate
the backend for dr-konqi on the server so that crash-reports could be
created as Issues in TGW. What is your opinion on this idea?
May be it is worth trying. But some system issues that cause crashes are
not exactly caused by issue in TDE. But you can try and see how it works
____________________________________________________
2:41 a.m.
On 2020/12/13 04:20 AM, Slávek Banko via tde-users wrote:
As I thought more about it, I had the idea that we
could try to integrate
the backend for dr-konqi on the server so that crash-reports could be
created as Issues in TGW. What is your opinion on this idea?
Yes, excellent suggestion. It makes perfect sense and fits nicely with our development
environment.
We should go this way!
Cheers
Michele
10:35 a.m.
On Sunday 13 of December 2020 03:41:02 Michele Calgaro via tde-users wrote:
On 2020/12/13 04:20 AM, Slávek Banko via tde-users
wrote:
Exactly. I assume it will save us work: we won't have to invent the
integration of a "crash report system" with TGW, we won't have to design
and create a UI for a crash report system, we'll get it all automatically.
And at the same time we will get other advantages: there it will be
possible to assign a crash report to a branch, set a milestone, it will be
possible to refer from / to other issues and pull requests, there it will
be possible to add comments - ask for more information, discuss
solutions,... we'll get it all automatically.
Cheers
--
Slávek
As I thought more about it, I had the idea that
we could try to
integrate the backend for dr-konqi on the server so that crash-reports
could be created as Issues in TGW. What is your opinion on this idea?
Yes, excellent suggestion. It makes perfect sense and fits nicely with
our development environment. We should go this way!
Cheers
Michele
1:21 p.m.
Exactly. I assume it will save us work: we won't
have to invent the
integration of a "crash report system" with TGW, we won't have to design
and create a UI for a crash report system, we'll get it all automatically.
And at the same time we will get other advantages: there it will be
possible to assign a crash report to a branch, set a milestone, it will be
possible to refer from / to other issues and pull requests, there it will
be possible to add comments - ask for more information, discuss
solutions,... we'll get it all automatically.
And we can switch it even without reaching out to Tim! :-)
Cheers
Michele
5:51 p.m.
On Sunday 13 December 2020 07:21:32 am Michele Calgaro via tde-users wrote:
I'll make the suggestion that the crash report doesn't even initiate on the
user's PC unless they have whatever (tool/library?) is needed to send a crash
report.
Why? It's always bugged me that something TDE crashes, a popup on my system
gets initiated, but since I don't have XYZ installed the crash popup then
tells me, "Never mind, I can't send anything anyway."
I'll make the second suggestion that if whatever XYZ is, is small disk space
wise, then XYZ should be either default installed or added to install docs
as, "Install this to generate crash reports."
On the second suggestion, it'd probably be best to link to whatever doc
explains exactly what gets included in crash reports, what security issues
they might have, what information might be leaked, etc... *
* I've never turned them on as I've never seen anything assuring me my
clients' data won't be breached in some way. As it is now, I sign so many
NDAs I can't take the risks.
Best,
Michael
Exactly. I
assume it will save us work: we won't have to invent the
integration of a "crash report system" with TGW, we won't have to design
and create a UI for a crash report system, we'll get it all
automatically. And at the same time we will get other advantages: there
it will be possible to assign a crash report to a branch, set a
milestone, it will be possible to refer from / to other issues and pull
requests, there it will be possible to add comments - ask for more
information, discuss
solutions,... we'll get it all automatically.
And we can switch it even without reaching out to Tim! :-)
Cheers
Michele
1470
days inactive
1472
days old
15 comments
6 participants
participants (6)
-
deloptes -
E. Liddell -
Michael -
Michele Calgaro -
Mike Bird -
Slávek Banko