[opensuse-buildservice] Qactus, a Qt-based OBS notifier app
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone! I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well. More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/ Cheers, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTw9SYACgkQdV3zWWOPFxSnNQCcCIq8DcTC09N14pHE6mappz8X 2MgAni2/g0/zdsWKlECO77+tCFWZuwc5 =BhlI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri 27 Feb 2015 11:52:22 PM CST, Javier Llorente wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
Hi Nice tool :) I've pushed a patched update to your OBS project to build/install and also included the 'optflags' to the build; https://build.opensuse.org/request/show/288358 I've also pushed the updates (and included the rpm spec file) to your GitHub project. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.36-38-default up 3 days 1:26, 5 users, load average: 0.29, 0.47, 0.49 CPU AMD A4-5150M APU @ 3.3GHz | GPU Richland Radeon HD 8350G -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 01/03/15 a las 20:20, Malcolm escribió:
On Fri 27 Feb 2015 11:52:22 PM CST, Javier Llorente wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
Hi Nice tool :)
I've pushed a patched update to your OBS project to build/install and also included the 'optflags' to the build; https://build.opensuse.org/request/show/288358
I've also pushed the updates (and included the rpm spec file) to your GitHub project.
Thanks! :) As you know, I have merged your changes. - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT0yaAACgkQdV3zWWOPFxSlqQCfX1gXArlv+H8Eyv5hh9hQxsct eO4An2rG1XcTCfyt1jYs01IULadWbtfJ =Flml -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/
Very cool :) Do you need better support in our API somewhere? Maybe to listen more comfortable any changes? You may want to check osc -d results -w You can see there how osc is monitoring changes by refering to the old known state so the http call hangs until something happened. Yet another idea, we could add some links in build.opensuse.org which can be dragged and dropped to qactus. qactus could use the URL to learn which which project/package/repo/arch or request should be monitored. Actually, you could do this already just by seperating the path of a link to some log file monitor for example ... In any case, we are happy to support you in any needs here :) thanks a lot for Qactus adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 02/03/15 a las 09:04, Adrian Schröter escribió:
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/
Very cool :)
Do you need better support in our API somewhere? Maybe to listen more comfortable any changes?
Right now what comes up to my mind is the following: - - having the possibility of downloading all the SRs and afterwads, when the user clicks on Qactus' refresh button, just downloading the new ones and not the whole collection again. I have also thought of making accepting/declining SRs from the Requests tab possible.
You may want to check
osc -d results -w
You can see there how osc is monitoring changes by refering to the old known state so the http call hangs until something happened.
This is quite interesting. Using it would be a radical change in terms of Qactus' architecture. One question: once the http call is terminated, would I need to retrieve the status making another http call? (ie: a standard GET https://api.o.o/build/prj/repo/arch/pkg/_status) What's the meaning of an asterisk next to a status? That it has changed recently? I haven't found its meaning on the man page.
Yet another idea, we could add some links in build.opensuse.org which can be dragged and dropped to qactus. qactus could use the URL to learn which which project/package/repo/arch or request should be monitored. Actually, you could do this already just by seperating the path of a link to some log file monitor for example ...
That's a cool idea. Drag and drop URLs from your browser directly into Qactus. As you said, I think no special links would be need. Qactus could differentiate URLs and get the package to be monitored from the URL as well.
In any case, we are happy to support you in any needs here :)
Thanks! :)
thanks a lot for Qactus adrian
Greetings, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT07sYACgkQdV3zWWOPFxSszwCghdsAJ3P/jWqriBG2KFBefo5l 1xEAnjoO/OEvQ9h/fuYobBi9l97rL3Oc =73ZX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Dienstag, 3. März 2015, 00:14:14 wrote Javier Llorente:
El 02/03/15 a las 09:04, Adrian Schröter escribió:
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/
Very cool :)
Do you need better support in our API somewhere? Maybe to listen more comfortable any changes?
Right now what comes up to my mind is the following:
- having the possibility of downloading all the SRs and afterwads, when the user clicks on Qactus' refresh button, just downloading the new ones and not the whole collection again.
hm, so you want some api call extension to say for example show only requests > number X? Should be easy to do ...
I have also thought of making accepting/declining SRs from the Requests tab possible.
You may want to check
osc -d results -w
You can see there how osc is monitoring changes by refering to the old known state so the http call hangs until something happened.
This is quite interesting. Using it would be a radical change in terms of Qactus' architecture. One question: once the http call is terminated, would I need to retrieve the status making another http call? (ie: a standard GET https://api.o.o/build/prj/repo/arch/pkg/_status)
No, the result comes with this root element for example: <resultlist state="ce111a8f5c883f9509c035ac6b1c24ff"> just use the content of the state attribute as parameter to tell the api what was your last state.
What's the meaning of an asterisk next to a status? That it has changed recently? I haven't found its meaning on the man page.
It can have two meanings in osc. Either it is the "dirty" flag, this means the server knows that the scheduler has to check the repository state again. For example when a source change happened, but the scheduler did not check the repository state yet. So the state may still be in succeeded/failed, but it is known that this is going to change. The other situation where osc prints the asterik is when the build has finished, but the repository is not yet published. When using --verbose switch you see a more detailed output here. This is the code in osc for this: if res['dirty']: waiting = True if verbose: res['status'] = 'outdated (was: %s)' % res['status'] else: res['status'] += '*' elif res['code'] in ('succeeded') and res['repostate'] != "published": waiting = True if verbose: res['status'] += '(unpublished)' else: res['status'] += '*'
Yet another idea, we could add some links in build.opensuse.org which can be dragged and dropped to qactus. qactus could use the URL to learn which which project/package/repo/arch or request should be monitored. Actually, you could do this already just by seperating the path of a link to some log file monitor for example ...
That's a cool idea. Drag and drop URLs from your browser directly into Qactus. As you said, I think no special links would be need. Qactus could differentiate URLs and get the package to be monitored from the URL as well.
Right, not for Drag&Drop. But we could also add links to click on. It would deliver some file with some specific mimetype so the desktop handler could deliver it to qactus. But that needs some more thinking about how to integrate it into current webui. good morning adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.03.2015 08:07, Adrian Schröter wrote:
On Dienstag, 3. März 2015, 00:14:14 wrote Javier Llorente:
El 02/03/15 a las 09:04, Adrian Schröter escribió:
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/
Very cool :)
Do you need better support in our API somewhere? Maybe to listen more comfortable any changes?
Right now what comes up to my mind is the following:
- having the possibility of downloading all the SRs and afterwads, when the user clicks on Qactus' refresh button, just downloading the new ones and not the whole collection again.
hm, so you want some api call extension to say for example show only requests > number X?
Should be easy to do ...
xpath already offers that. It doesn't really fit in the view=collection API IMO. So my recommendation would be to load a view=collection and after that do the polling through xpath and filter in the client. Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT1gUwACgkQwFSBhlBjoJZMVwCcCtM6KVpyZkZLghOeFEMRdPNd Z8QAmQFSE1X7ae91kAArlOfuhfPlYuGd =CGeB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 03/03/15 a las 08:07, Adrian Schröter escribió:
On Dienstag, 3. März 2015, 00:14:14 wrote Javier Llorente:
El 02/03/15 a las 09:04, Adrian Schröter escribió:
On Freitag, 27. Februar 2015, 23:52:22 wrote Javier Llorente:
Hello everyone!
I have just released the first version of Qactus, a Qt-based OBS notifier application. Besides the build status viewer, it features an autocompleter for adding builds to the list easily and a submit request viewer as well.
More details are available at http://www.javierllorente.com/2015/02/27/qactus-is-out-in-the-wild/
Very cool :)
Do you need better support in our API somewhere? Maybe to listen more comfortable any changes?
Right now what comes up to my mind is the following:
- having the possibility of downloading all the SRs and afterwads, when the user clicks on Qactus' refresh button, just downloading the new ones and not the whole collection again.
hm, so you want some api call extension to say for example show only requests > number X?
Should be easy to do ...
That or retrieving only new requests since a certain date (when user clicks on refresh, for example)
I have also thought of making accepting/declining SRs from the Requests tab possible.
You may want to check
osc -d results -w
You can see there how osc is monitoring changes by refering to the old known state so the http call hangs until something happened.
This is quite interesting. Using it would be a radical change in terms of Qactus' architecture. One question: once the http call is terminated, would I need to retrieve the status making another http call? (ie: a standard GET https://api.o.o/build/prj/repo/arch/pkg/_status)
No, the result comes with this root element for example:
<resultlist state="ce111a8f5c883f9509c035ac6b1c24ff">
just use the content of the state attribute as parameter to tell the api what was your last state.
So no need for comparing build status in this case; 1) Wait until something happens (which means finished building). This terminates the http call. 2) If something has happened, you get the "resultlist" with the new build status. 3) After this you can keep monitoring the build status by making the same http call with the content of the state attribute you got in "resultlist" as "oldstate", and the process starts over. Qactus could end up with quite a few http connections open. - From this I have got the idea of monitoring a build for any arch/repository. The current version of Qactus just requests "_status" That's it, you can only add a build for only one arch/repository at a time. It stores the last status tag and compares it against the most recent one to see if there have been any changes.
What's the meaning of an asterisk next to a status? That it has changed recently? I haven't found its meaning on the man page.
It can have two meanings in osc. Either it is the "dirty" flag, this means the server knows that the scheduler has to check the repository state again. For example when a source change happened, but the scheduler did not check the repository state yet. So the state may still be in succeeded/failed, but it is known that this is going to change.
The other situation where osc prints the asterik is when the build has finished, but the repository is not yet published.
When using --verbose switch you see a more detailed output here. This is the code in osc for this:
if res['dirty']: waiting = True if verbose: res['status'] = 'outdated (was: %s)' % res['status'] else: res['status'] += '*' elif res['code'] in ('succeeded') and res['repostate'] != "published": waiting = True if verbose: res['status'] += '(unpublished)' else: res['status'] += '*'
OK. Thanks for explaining it.
Yet another idea, we could add some links in build.opensuse.org which can be dragged and dropped to qactus. qactus could use the URL to learn which which project/package/repo/arch or request should be monitored. Actually, you could do this already just by seperating the path of a link to some log file monitor for example ...
That's a cool idea. Drag and drop URLs from your browser directly into Qactus. As you said, I think no special links would be need. Qactus could differentiate URLs and get the package to be monitored from the URL as well.
Right, not for Drag&Drop. But we could also add links to click on. It would deliver some file with some specific mimetype so the desktop handler could deliver it to qactus.
But that needs some more thinking about how to integrate it into current webui.
Yet another good idea. That reminds me of YaST's one click install. I have created a wiki page with the TODO/ideas and added yours. https://github.com/javierllorente/qactus/wiki
good morning adrian
Greetings, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT2SegACgkQdV3zWWOPFxQC0ACfeJ7dUZOnwnDezjIEVXTMhhSX dY4An2eWJwYfMY/FP/kVOHuyh4FGz9Lo =6jiM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday, March 04, 2015 12:55:20 AM Javier Llorente wrote:
I have created a wiki page with the TODO/ideas and added yours. https://github.com/javierllorente/qactus/wiki
Hi Javier, As that we are brainstorming anyway, maybe an idea would be to be able to see all requests open for a certain group ? In my situation I am getting SR's for packages I maintain, but also for the whole repository (e.g. KDE:Extra) and on top of that I am part of the review group for Factory. It would be great if Qactus could listen to SR's that are open for a certain group or person. Thanks Raymond -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 04/03/15 a las 09:45, Raymond Wooninck escribió:
On Wednesday, March 04, 2015 12:55:20 AM Javier Llorente wrote:
I have created a wiki page with the TODO/ideas and added yours. https://github.com/javierllorente/qactus/wiki
Hi Javier,
As that we are brainstorming anyway, maybe an idea would be to be able to see all requests open for a certain group ? In my situation I am getting SR's for packages I maintain, but also for the whole repository (e.g. KDE:Extra) and on top of that I am part of the review group for Factory.
It would be great if Qactus could listen to SR's that are open for a certain group or person.
I get your idea of getting group SRs but not the person part. Do you mean seeing SRs concerning other person? Thanks, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT26KAACgkQdV3zWWOPFxRV4ACfSTwYcHwkQRrc2fa7xAs5RfS3 LqAAn0aOYS9fjezOXCNmYxfX6woPASFR =3KdU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday, March 04, 2015 12:12:32 PM Javier Llorente wrote:
It would be great if Qactus could listen to SR's that are open for a certain group or person.
I get your idea of getting group SRs but not the person part. Do you mean seeing SRs concerning other person?
Hi Javier, Not regarding an other person, but what I understood is that the current functionality is showing the requests for those packages that are monitored within Qactus. If you maintain a package which is not monitored, you will not see the request. At least that is my current understanding, so it would be a great functionality if you could see all the SR's and Reviews that are for you (either as a person or as part of a group). Regards Raymond -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 04/03/15 a las 13:11, Raymond Wooninck escribió:
On Wednesday, March 04, 2015 12:12:32 PM Javier Llorente wrote:
It would be great if Qactus could listen to SR's that are open for a certain group or person.
I get your idea of getting group SRs but not the person part. Do you mean seeing SRs concerning other person?
Hi Javier,
Not regarding an other person, but what I understood is that the current functionality is showing the requests for those packages that are monitored within Qactus. If you maintain a package which is not monitored, you will not see the request. At least that is my current understanding, so it would be a great functionality if you could see all the SR's and Reviews that are for you (either as a person or as part of a group).
The current release of Qactus retrieves all your SRs, no matter if you are monitoring that particular package or not on Qactus. What is missing is retrieving by group. Greetings, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlT3PEEACgkQdV3zWWOPFxTpHACfQf5gT8wglIVP064zMxZ8W4hd jKoAn3lM+3z5XAkBXwCZhfHZzYv+zKZx =Omok -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (5)
-
Adrian Schröter -
Javier Llorente -
Malcolm -
Raymond Wooninck -
Stephan Kulow