Re: kaudiocreator to unmaintained

[Bernd Steinhauser]

On 22/05/19 13:39, Jonathan Riddell wrote:
On Tue, 21 May 2019 at 17:48, Kevin Ottens > wrote:


> Will you make releases?

I'd like it to be part of KDE Applications. Unlike Zanshin I'd rather have
this one tied to the Applications release cycle. That being said, it's been
eons since I had anything in the regular applications collection. Could
someone refresh me on what it entails to "make release"? Back in the day it
was fairly transparent, if that's still so low on work I can easily say
yes...
if not I'll have to evaluate.


Great, please work with Albert or whoever to get it into the KDE Applications 
bundle.


One of the first issues I see is the screenshot needs updating, this can be 
done here

https://cgit.kde.org/websites/product-screenshots.git/tree/README.md
You may also want to update the metadata in the appstream .xml file, currently 
it generates this:

http://apps.kde.org.uk/applications/unmaintained/org.kde.kaudiocreator

Jonathan


Did you guys have a look at audex?
Last time I looked at both audex and kaudiocreator, I found the former to be in 
a much better state.
That's also why I put in some effort to port it to kf5 (at the time neither of 
the two was ported).


Right now the main issue with audex is that the cover fetching doesn't work 
(since Google removed a related API), but apart from that it works very well.


Of course, if you – for whatever reason – prefer kaudiocreator, feel free to 
continue with that one.

Just wanted to point out that audex exists as well. ;)

Cheers,
Bernd

Re: Review Request 118763: Remove find_package(XCB) call as it is handled already by the top-level cmake file

[Bernd Steinhauser]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118763/
---

(Updated Aug. 22, 2014, 3:31 p.m.)


Status
--

This change has been marked as submitted.


Review request for kde-workspace, Plasma and Hugo Pereira Da Costa.


Repository: oxygen


Description
---

No idea if kde-workspace is still the right group, if not, please change.

find_package(XCB) is called without specifying the required components. This 
leads to linking to unused dependencies in case they are installed.

Since XCB is searched for in the top level cmake file in the repository, there 
is no need to search for it again. The component required there (only base XCB) 
is sufficient.
Although, this should be sufficient to fix the deps problem, it makes sense to 
link to XCB::XCB instead of ${XCB_LIBRARIES}, since the former is what is 
actually needed.


Diffs
-

  kstyle/CMakeLists.txt 165b62a 
  liboxygen/CMakeLists.txt 0d1dd94 

Diff: https://git.reviewboard.kde.org/r/118763/diff/


Testing
---


Thanks,

Bernd Steinhauser

Re: Review Request 118763: Remove find_package(XCB) call as it is handled already by the top-level cmake file

[Bernd Steinhauser]

 On June 26, 2014, 11:49 a.m., Hugo Pereira Da Costa wrote:
  Ship It!
 
 Hugo Pereira Da Costa wrote:
 Ping ? Should I commit this myself ?

Yes, please commit this. I don't have commit access myself.


- Bernd


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118763/#review61017
---


On June 16, 2014, 2:07 p.m., Bernd Steinhauser wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118763/
 ---
 
 (Updated June 16, 2014, 2:07 p.m.)
 
 
 Review request for kde-workspace, Plasma and Hugo Pereira Da Costa.
 
 
 Repository: oxygen
 
 
 Description
 ---
 
 No idea if kde-workspace is still the right group, if not, please change.
 
 find_package(XCB) is called without specifying the required components. This 
 leads to linking to unused dependencies in case they are installed.
 
 Since XCB is searched for in the top level cmake file in the repository, 
 there is no need to search for it again. The component required there (only 
 base XCB) is sufficient.
 Although, this should be sufficient to fix the deps problem, it makes sense 
 to link to XCB::XCB instead of ${XCB_LIBRARIES}, since the former is what is 
 actually needed.
 
 
 Diffs
 -
 
   kstyle/CMakeLists.txt 165b62a 
   liboxygen/CMakeLists.txt 0d1dd94 
 
 Diff: https://git.reviewboard.kde.org/r/118763/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bernd Steinhauser
 

Re: Review Request 118763: Remove find_package(XCB) call as it is handled already by the top-level cmake file

[Bernd Steinhauser]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118763/
---

(Updated June 16, 2014, 2:07 p.m.)


Review request for kde-workspace, Plasma and Hugo Pereira Da Costa.


Repository: oxygen


Description
---

No idea if kde-workspace is still the right group, if not, please change.

find_package(XCB) is called without specifying the required components. This 
leads to linking to unused dependencies in case they are installed.

Since XCB is searched for in the top level cmake file in the repository, there 
is no need to search for it again. The component required there (only base XCB) 
is sufficient.
Although, this should be sufficient to fix the deps problem, it makes sense to 
link to XCB::XCB instead of ${XCB_LIBRARIES}, since the former is what is 
actually needed.


Diffs
-

  kstyle/CMakeLists.txt 165b62a 
  liboxygen/CMakeLists.txt 0d1dd94 

Diff: https://git.reviewboard.kde.org/r/118763/diff/


Testing
---


Thanks,

Bernd Steinhauser

Review Request 118763: Remove find_package(XCB) call as it is handled already by the top-level cmake file

[Bernd Steinhauser]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118763/
---

Review request for kde-workspace.


Repository: oxygen


Description
---

No idea if kde-workspace is still the right group, if not, please change.

find_package(XCB) is called without specifying the required components. This 
leads to linking to unused dependencies in case they are installed.

Since XCB is searched for in the top level cmake file in the repository, there 
is no need to search for it again. The component required there (only base XCB) 
is sufficient.
Although, this should be sufficient to fix the deps problem, it makes sense to 
link to XCB::XCB instead of ${XCB_LIBRARIES}, since the former is what is 
actually needed.


Diffs
-

  kstyle/CMakeLists.txt 165b62a 
  liboxygen/CMakeLists.txt 0d1dd94 

Diff: https://git.reviewboard.kde.org/r/118763/diff/


Testing
---


Thanks,

Bernd Steinhauser

Re: Qt 5.3 to log all debug/warning/error messages to journald on systemd systems

[Bernd Steinhauser]

Àlex Fiestas wrote:

 On Monday 20 January 2014 14:40:17 Thiago Macieira wrote:
 See subject. We're trying to decide whether we should enable journald by
 default on Linux distributions that carry it. If we do, it means any
 application that is not launched from a terminal would automatically
 write to journald instead.
 
 KDE applications are the largest users of qDebug today.
 
 If we changed the default, it would mean ~/.xsession-errors would
 probably become rather empty. Is that ok for KDE?
 
 I have even thought on writing this myself... so a big +1
 
 I'm really looking forward to be able to tell my users in bug reports
 something like:
 Prove the output from: journalctl /usr/bin/bluedevil-wizard :33
Hi,

I'm not a KDE Developer, so sorry for writing to this list, but I'm 
answering here, because this is almost exactly what I wanted to propose as a 
feature request on bugzilla (or via mail) recently.

First, I submitted a couple of bug request during the last few years, so I 
spent quite some time digging through .xsession-errors and this was always 
quite painful, because it's sometimes not very easy to find out which 
program caused which messages (most messages are prepended by the program 
name, but not all of them). Depending on how kde is built and set up, there 
can be *a lot* of information in that file and it can quite easily grow up 
to several hundreds of megabytes (sometimes without the user noticing).

Now with journalctl, this would be quite different. As Alex noted, filtering 
per app is possible, but also a lot of other filtering. With MaxLevelStore, 
debug information can normally filtered out and activated when trying to 
reproduce a problem (to avoid flooding the log, although that's not a huge 
problem for journald anyway), journald supports rotating logs due to size, 
so the used disk space can be controled much better than with .xsession-
errors (keep in mind that logs are very well compressed by a factor of 
40-50). That gets never rotated unless done manually, except, that it is 
cleaned on login.

So going even one step further than what Alex suggested: The bug report tool 
already shows a backtrace if a process crashed including a rating to show if 
it might be helpful or not. The same could be done with the logs.
When a program crashes, the tool could (based on the pid) get the output of 
that program since it was started (that should be quite easy to find out) 
and there could even be a rating if that log information might be helpful or 
not. I don't know if something like that is implemented in journald, but 
maybe a program could automatically gather debug information which might not 
be stored on the disk due to configuration? At least it might be an idea.

In the end, I think it would result in better bug reports (and therefore 
hopefully easier bug fixing).

Cheers,
Bernd