Bug 382754

> Forcing unsuspecting users to use a development alternative to cdrecord which works fine for years.

Really? I argue that https://lists.debian.org/debian-devel-announce/2006/09/msg00002.html so please remove wodim (forked cdrecord) from cdrkit (CD only, DVD deprecated, unmaintained), website was down, release tarball is NOT available, svn repos is so quiet! But install cdrtools A.K.A cdrecord instead. http://www.leetcode.cn/2016/08/k3b.html#bug

(In reply to Leslie Zhai from comment #1)
> > Forcing unsuspecting users to use a development alternative to cdrecord which works fine for years.
> 
> Really? I argue that
> https://lists.debian.org/debian-devel-announce/2006/09/msg00002.html so
> please remove wodim (forked cdrecord) from cdrkit (CD only, DVD deprecated,
> unmaintained), website was down, release tarball is NOT available, svn repos
> is so quiet! But install cdrtools A.K.A cdrecord instead.
> http://www.leetcode.cn/2016/08/k3b.html#bug

We've had cdrtools a.k.a. cdrecord in openSUSE for a few years and had no problems, I can understand the problem with distributions that don't want to use schilly's program but it's well maintained and it works.
openSUSE:Leap:42.3 is supposed to be a stable lts release and it appears that cdrskin is still in development. There should be a switch to disable this message for those who wish to use cdrecord.
My question is will k3b still function as expected without cdrskin or do we have to require cdrskin? I don't see anything relating to cdrskin in CMakeLists,txt.
See also https://bugzilla.suse.com/show_bug.cgi?id=1050715

Git commit 52a2493f77c1ed6cc77bdeb2dceb2afb51cda815 by Leslie Zhai.
Committed on 27/07/2017 at 06:08.
Pushed by lesliezhai into branch 'master'.

Update problem's message about missing cdrskin at start up.

Thomas Schmitt, the core developer of libburn, taught me to implement
K3b::CdrskinWriter to fix BUG 137436, and Cristian Aravena Romero helped
us to test cdrskin see BUG 380067

CCMAIL: scdbackup@gmx.net

M  +1    -1    src/k3bsystemproblemdialog.cpp

https://commits.kde.org/k3b/52a2493f77c1ed6cc77bdeb2dceb2afb51cda815

> My question is will k3b still function as expected without cdrskin or do we have to require cdrskin?

Next question, which version of libburn/cdrskin is stable. Ironically I tried to submit the latest libburn to Leap:42.3 just before freeze last month and it wasn't considered necessary. I maintain multimedia and not kde so I didn't have a clue about this then.

Hi Dave,

> My question is will k3b still function as expected without cdrskin or do we have to require cdrskin? I don't see anything relating to cdrskin in CMakeLists,txt.
See also https://bugzilla.suse.com/show_bug.cgi?id=1050715

Sorry that I don't have the account to login SUSE's bugzilla, and not prefer to provide too much my personal information when registering, please help me to quote my comments for K3B's users, thanks!

1. I don't know the quality of cdrtools (AKA cdrecord), but we know cdrkit, dvd+rw-tools, libburnia, libisoburn and even Linux Kernel :) http://www.leetcode.cn/2016/11/analyzing-code-for-kde-qt-open-source-components.html

2. only Thomas Schmitt, the core developer of libburnia, taught me about ISO 9660 and MMC knowledage, helped me to fix BUG 367639  and more than that https://mail.kde.org/pipermail/k3b

So I prefer to use cdrskin personally and K3B is still able to work without it, but just show the problem messages if the user choose other utilities and libraries which not maintained any more and deprecated.

Regards,
Leslie Zhai - a LLVM developer https://reviews.llvm.org/p/xiangzhai/

(In reply to davejplater@gmail.com from comment #5)
> Next question, which version of libburn/cdrskin is stable. Ironically I
> tried to submit the latest libburn to Leap:42.3 just before freeze last
> month and it wasn't considered necessary. I maintain multimedia and not kde
> so I didn't have a clue about this then.

ping Thomas and Cc to him :)

Hi,

the current upstream release of libburn and cdrskin is 1.4.6.
Since then there were not many significant changes in the development
version 1.4.7, which one can derive from

  git clone git@dev.lovelyhq.com:libburnia/libburn.git

* Bug fix: Option -dummy did not affect writing by direct_write_amount=

* Refusing to write to BD-R if formatted to Pseudo Overwrite

The former does hardly affect K3B.

The latter might be interesting for K3B, because libburn 1.4.6 tries to
append sessions to growisofs burnt appendable BD-R media, but spoils
them because growisofs formatted them to Pseudo-Overwrite state.
libburn-1.4.8 will refuse to start writing on such media.

K3B could detect that medium state MEDIA_BD_R_SRM_POW is present and
refuse to let cdrskin write to such a medium. See
  https://www.mail-archive.com/kde-bugs-dist@kde.org/msg77288.html
for code snippets which mention that state.

Have a nice day :)

Thomas

(In reply to Leslie Zhai from comment #6)
> but just show the problem messages if the user choose other utilities
> and libraries which not maintained any more and deprecated.

But cdrecord is maintained and not deprecated.

Maybe the message should be reworded to state that cdrskin is *optional*, and k3b will use it in place of cdrecord *if it is installed*. I.e. make it clear that burning will still be possible without cdrskin installed.

One thing though: I tried to install cdrskin here. This removed the message on startup, but k3b (17.04.3) still seems to use cdrecord according to its output.
Uninstalling cdrecord gave an error message on startup that it is missing and broke burning completely even with cdrskin installed (and it is detected in the settings dialog).

So apparently cdrskin is not even used currently for some reason?

(In reply to Wolfgang Bauer from comment #9)
> (In reply to Leslie Zhai from comment #6)
> > but just show the problem messages if the user choose other utilities
> > and libraries which not maintained any more and deprecated.
> 
> But cdrecord is maintained and not deprecated.
> 
> Maybe the message should be reworded to state that cdrskin is *optional*,
> and k3b will use it in place of cdrecord *if it is installed*. I.e. make it
> clear that burning will still be possible without cdrskin installed.
> 
> One thing though: I tried to install cdrskin here. This removed the message
> on startup, but k3b (17.04.3) still seems to use cdrecord according to its
> output.
> Uninstalling cdrecord gave an error message on startup that it is missing
> and broke burning completely even with cdrskin installed (and it is detected
> in the settings dialog).
> 
> So apparently cdrskin is not even used currently for some reason?

BUG 137436

but Cristian Aravena Romero helped us to test cdrskin see BUG 380067

and of course I can enable cdrskin as default writter to take place of cdrecord, or even totally disable it.

(In reply to Leslie Zhai from comment #10)
> (In reply to Wolfgang Bauer from comment #9)
> > (In reply to Leslie Zhai from comment #6)
> > > but just show the problem messages if the user choose other utilities
> > > and libraries which not maintained any more and deprecated.
> > 
> > But cdrecord is maintained and not deprecated.
> > 
> > Maybe the message should be reworded to state that cdrskin is *optional*,
> > and k3b will use it in place of cdrecord *if it is installed*. I.e. make it
> > clear that burning will still be possible without cdrskin installed.
> > 
> > One thing though: I tried to install cdrskin here. This removed the message
> > on startup, but k3b (17.04.3) still seems to use cdrecord according to its
> > output.
> > Uninstalling cdrecord gave an error message on startup that it is missing
> > and broke burning completely even with cdrskin installed (and it is detected
> > in the settings dialog).
> > 
> > So apparently cdrskin is not even used currently for some reason?
> 
> BUG 137436
> 
> but Cristian Aravena Romero helped us to test cdrskin see BUG 380067
> 
> and of course I can enable cdrskin as default writter to take place of
> cdrecord, or even totally disable it.

disable cdrecord, but if the user prefer to use it, please though command line, not k3b, thanks!

(In reply to Leslie Zhai from comment #11)
> > and of course I can enable cdrskin as default writter to take place of
> > cdrecord, or even totally disable it.
> 
> disable cdrecord, 

Of course you can, but that's not the case at the moment.
Does that mean you plan to do that in the near future?

But as I wrote, cdrskin doesn't seem to be used at all currently here.
So currently the message seems bogus anyway to me.

Or am I misunderstanding something? (e.g. is it only used for DVDs/BDs? I only tested CDs)

> but if the user prefer to use it, please though command
> line, not k3b, thanks!

And why?
It works (since years), it is maintained upstream. And actually it seems to be used by k3b here even with cdrskin installed.

(In reply to Wolfgang Bauer from comment #12)
> (In reply to Leslie Zhai from comment #11)
> > > and of course I can enable cdrskin as default writter to take place of
> > > cdrecord, or even totally disable it.
> > 
> > disable cdrecord, 
> 
> Of course you can, but that's not the case at the moment.
> Does that mean you plan to do that in the near future?

when cdrskin and related utilities are able to cover all user cases https://bugs.kde.org/show_bug.cgi?id=137436#c20 

> 
> But as I wrote, cdrskin doesn't seem to be used at all currently here.
> So currently the message seems bogus anyway to me.
> 
> Or am I misunderstanding something? (e.g. is it only used for DVDs/BDs? I
> only tested CDs)
> 
> > but if the user prefer to use it, please though command
> > line, not k3b, thanks!
> 
> And why?

the good compiler is depends on tons of source code tuning, and cdrskin also need more users to use and test :)

> It works (since years), it is maintained upstream. And actually it seems to
> be used by k3b here even with cdrskin installed.

it is easy to use clang analyzer, sanitizer, libfuzzer, or commercial utilities to analysis cdrecord source code http://www.leetcode.cn/2016/11/analyzing-code-for-kde-qt-open-source-components.html and welcome benchmark.

Just to shed a bit of light. openSUSE worked with Jörg Schilling to have cdrecord/cdrtools in the distribution in 2013 due to numerous bugs with wodim/cdrkit-cdrtools-compat particularly with k3b. It has been a part of the distribution since 13.2 2013-12-04 and has performed very well since then but it has been installed from alternate repositories many years prior due to wodim problems.
@Leslie Zhai you can understand our concerns about changing something that is proven for something that is new.

Hi,

just as technical background info:

libburn underneath cdrskin is well tested since 10 years.
It supports CD data and CD audio, but not the more exotic CD sector
formats, simply because i lack of any test user or test case for
those CD sectors.
With DVD and BD media, it can compete with growisofs, which is
preferred by K3B over cdrecord for a reason. 

A main advantage for users is that libburn can disable Defect Management
on BD-RE media. This makes burning as fast as the nominal speed of
the medium (i.e. 2x rather than 0.9x) and it keeps media usable which
Defect Management would swamp with replacement blocks although the
original blocks are still good enough.
Like cdrecord it does not format BD-R by default, thus yielding full
speed on BD-R media.

I provide support for libburn (and growisofs if necessary). Its bug
list at least on Debian is clean. If SuSE has open bugs, please forward
them to pkg-libburnia-devel@lists.alioth.debian.org.

Elsewise, everybody should be free to choose the burn backend which one
likes most. No need to quarrel.

Have a nice day :)

Thomas

(In reply to davejplater@gmail.com from comment #14)
> Just to shed a bit of light. openSUSE worked with Jörg Schilling to have
> cdrecord/cdrtools in the distribution in 2013 due to numerous bugs with
> wodim/cdrkit-cdrtools-compat particularly with k3b. It has been a part of
> the distribution since 13.2 2013-12-04 and has performed very well since
> then but it has been installed from alternate repositories many years prior
> due to wodim problems.
> @Leslie Zhai you can understand our concerns about changing something that
> is proven for something that is new.

Disabled check system config by default https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp#L723

Just to be clear here: It is not my intention to "quarrel" over whether k3b should use cdrskin or cdrecord. Actually I don't mind personally (openSUSE does have both), as long as it works (and to avoid a possible misunderstanding: I have no reason to believe nor do I want to suggest that cdrskin does not work).
Although I don't see a good reason to drop support for cdrecord either. Keep both and prefer cdrskin if you want, I'd say... ;-) 

I just wanted to note that I find the message a bit misleading, as long as cdrecord is supported.

Also I'd like to repeat that according to my tests, cdrecord is actually *mandatory* and cdrskin is not even used if it's installed, contrary to the message. (for CDs at least, I don't have a DVD or BD burner to try)

(In reply to Leslie Zhai from comment #16)
> Disabled check system config by default
> https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp#L723

Not really. As I understand the code, the line before explicitly sets it to true on first start (or whenever k3b is updated to a new version).
Also, that would affect the whole system problems dialog, not just the cdrskin message. I'm not sure it's a good idea to disable that by default (especially now that the "do not show again" option works again... ;-) ).

Hi,

In
  https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp
it should not be recorded as CRITICAL if only one of cdrecord or cdrskin
is not usable.

A quick solution would be to report the messages preliminarily as
NON_CRITICAL and to check at the end of the burn program tests whether
both are missing.
If so, one would issue a CRITICAL message saying that no CD burn program
for cdrecord compatible options was found.

---------------------------------------------------------------------

In general the relation of the burn programs is wrongly represented in
this piece of code.

The programs overlap with their capabilites. If you just want to burn
a DVD-R with write type DAO, then growisofs, cdrecord, and cdrskin are
all three valid candidates for that.
If you want to burn CD XA or fast BD-RE multi-session, then two of
the three are not suitable.

So the severity evaluation should be delayed until it is clear how many of
the burn programs are available, and which tasks they can cover.

Consider something like this (properly adapted to K3B idiom, of course):

  struct burn_candidate {
    char *name;
    char *path;
    char *purpose;
    char *remarks[8];

    /* Problems, restrictions, or reasons for being unusable */
    int permission_problem;
    int does_not_exist;
    int is_outdated;
    int too_much_root;
    int not_enough_root;
    int would_need_atapi;
    ... maybe more ...

    /* Program capabilities */
    int does_cd_data;
    int does_cd_audio;
    int does_cd_other;
    int does_cd_multi_session;
    int does_cd_by_options;
    int does_cd_by_cue;
    int does_dvd;
    int does_dvd_multi_session;
    int does_bd;
    int does_bd_multi_session;
    int does_overwritable_multi_session;
    int does_fast_bdre;
    ... maybe more ...
  };

There would be an array of them with an element for each program that
may be used.
The tests would assess the problems and capabilities but not yet call
problems.append().
They would rather record the parameters needed for the messages.

When all assessment is done, one would next look which programs are
actually usable and which capabilities are covered by them.

If an important capapability is not covered by a usable program,
then this is should be reported as CRITICAL.
Further one could at this point choose the default programs for the
various tasks which demand the covered capabilities.

(Another burn backend K3B could encounter is "xorrecord", which is the
 cdrecord options emulation of xorriso. CD, DVD, BD. Data only. No audio.
 Based on libburn like cdrskin.)

---------------------------------------------------------------------

Before declaring a capability to be covered, the programmer will have
to verify that K3B can actually use that program for that task.
I.e. is K3B prepared to produce the necessary options ?
Can the program really do what the options demand ?

So, this proposal would cause substantial work and review of the
existing K3B code that controls the backend runs.


Have a nice day :)

Thomas

(In reply to Thomas Schmitt from comment #18)
> Hi,
> 
> In
>   https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp
> it should not be recorded as CRITICAL if only one of cdrecord or cdrskin
> is not usable.
> 
> A quick solution would be to report the messages preliminarily as
> NON_CRITICAL and to check at the end of the burn program tests whether
> both are missing.
> If so, one would issue a CRITICAL message saying that no CD burn program
> for cdrecord compatible options was found.
> 
> ---------------------------------------------------------------------
> 
> In general the relation of the burn programs is wrongly represented in
> this piece of code.
> 
> The programs overlap with their capabilites. If you just want to burn
> a DVD-R with write type DAO, then growisofs, cdrecord, and cdrskin are
> all three valid candidates for that.
> If you want to burn CD XA or fast BD-RE multi-session, then two of
> the three are not suitable.
> 
> So the severity evaluation should be delayed until it is clear how many of
> the burn programs are available, and which tasks they can cover.
> 
> Consider something like this (properly adapted to K3B idiom, of course):
> 
>   struct burn_candidate {
>     char *name;
>     char *path;
>     char *purpose;
>     char *remarks[8];
> 
>     /* Problems, restrictions, or reasons for being unusable */
>     int permission_problem;
>     int does_not_exist;
>     int is_outdated;
>     int too_much_root;
>     int not_enough_root;
>     int would_need_atapi;
>     ... maybe more ...
> 
>     /* Program capabilities */
>     int does_cd_data;
>     int does_cd_audio;
>     int does_cd_other;
>     int does_cd_multi_session;
>     int does_cd_by_options;
>     int does_cd_by_cue;
>     int does_dvd;
>     int does_dvd_multi_session;
>     int does_bd;
>     int does_bd_multi_session;
>     int does_overwritable_multi_session;
>     int does_fast_bdre;
>     ... maybe more ...
>   };

very good suggestion!

k3b use too simple `QStringList` https://github.com/KDE/k3b/blob/master/libk3b/core/k3bexternalbinmanager.cpp#L64 

1. addFeature, for example: https://github.com/KDE/k3b/blob/master/libk3b/core/k3bdefaultexternalprograms.cpp#L551

2. hasFeature, for example: https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bcdrskinwriter.cpp#L216

it needs more detailed feature checker for cdrecord, growisofs, cdrdao and other K3bConcreteWriter.


> 
> There would be an array of them with an element for each program that
> may be used.
> The tests would assess the problems and capabilities but not yet call
> problems.append().
> They would rather record the parameters needed for the messages.
> 
> When all assessment is done, one would next look which programs are
> actually usable and which capabilities are covered by them.
> 
> If an important capapability is not covered by a usable program,
> then this is should be reported as CRITICAL.
> Further one could at this point choose the default programs for the
> various tasks which demand the covered capabilities.
> 
> (Another burn backend K3B could encounter is "xorrecord", which is the
>  cdrecord options emulation of xorriso. CD, DVD, BD. Data only. No audio.
>  Based on libburn like cdrskin.)
> 
> ---------------------------------------------------------------------
> 
> Before declaring a capability to be covered, the programmer will have
> to verify that K3B can actually use that program for that task.
> I.e. is K3B prepared to produce the necessary options ?
> Can the program really do what the options demand ?
> 
> So, this proposal would cause substantial work and review of the
> existing K3B code that controls the backend runs.

yes, k3b will emit infoMessage about MessageError when be lack of some feature during the prepareProcess before the actual burning job, for example: https://github.com/KDE/k3b/blob/master/libk3b/projects/k3bcdrskinwriter.cpp#L245

and it is better to provide detailed checkSystem at startup, so users might install missing packages if desire some features, thoughts?


> 
> 
> Have a nice day :)
> 
> Thomas

Hi,

Leslie Zhai wrote:
> it needs more detailed feature checker for cdrecord, growisofs, cdrdao
> and other K3bConcreteWriter.
> [...]
> it is better to provide detailed checkSystem at startup, so users might
> install missing packages if desire some features, thoughts?

If i may think big, then i imagine two checks: One at program start to
verify that a roughly sufficient set of burn backends is available.
The second check would be made late when all needs of the K3B task
are determined. It could choose a burn program which matches those needs.

Refining my rough struct sketch, i would create a class that represents
the program capabilities and the task needs. Probably with an array and
named indice instead of single "does_some_thing" integers.

  #define DOES_NEEDS_BYTES        2

  #define DOES_NEEDS_CD_DATA      0
  ...
  #define DOES_NEEDS_FAST_BDRE   11

  unint_8 capabilities_or_needs[DOES_NEEDS_BYTES];

A capability (e.g. DOES_NEEDS_FAST_BDRE) would be marked by value 1 in 

  (capabilities_or_needs[DOES_NEEDS_FAST_BDRE / 8] 
   >> (DOES_NEEDS_FAST_BDRE % 8)) & 1

Both the drive examinations and the task preparation would fill out
such class instances.
The arrays of capabilities_or_needs[] would be compared by logical AND
operations. If the result is the same as the needs array, then the program
is fully suitable for the task.
If the result has less bits than the needs array, then some capabilities
are missing. In this case another burn program would have to be chosen,
or the task would have to be refused (with hints how to get it doable).


Above bit array would work well if all capabilities are yes/no decisions.
If we expect to get more possible values for a single capability, then
one should rather use a byte or integer array:

  #define DOES_NEEDS_BYTES       12
  #define DOES_NEEDS_CD_DATA      0
  ...
  #define DOES_NEEDS_FAST_BDRE   11
  unint_8 capabilities_or_needs[DOES_NEEDS_BYTES];

Here the macros are not but indice but rather byte indice:

  capabilities_or_needs[DOES_NEEDS_FAST_BDRE]

Comparison would not be done by AND but rather by "==" comparison of the
single array bytes.


The DOES_NEEDS class would then become a member of a BURN_PROG_ASSESS
class which contains the rest of information from my sketched
struct burn_candidate: name, permission_problem, ...

The early burn program assessment would fill out BURN_PROG_ASSESS class
instances and record them for use with the later check for task needs.
It would already warn if some generally important capabilities are not
covered by the detected burn programs.

The K3B task preparation would fill out a DOES_NEEDS instance and submit
it for comparison with those registered BURN_PROG_ASSESS instances, which
have no fatal problems.
This comparison would yield a list of suitable BURN_PROG_ASSESS instances
among which K3B or its user may chose for that particular task.

------------------------------------------------------------------------

But before working on that big structural change, i would first roughly
fix the check for cdrecord and cdrskin, so that they are considered
as alternatives for the main use cases of audio and data burn runs.

Further i would examine the report that cdrskin is not used when it should.
As Wolfgang Bauer wrote:
> cdrecord is actually *mandatory* and cdrskin is not even used if it's
> installed, contrary to the message.

And this bug report should be made open again. Currently it says
"Status: RESOLVED FIXED" which seems not to be true yet.


Have a nice day :)

Thomas

Git commit 4a6aa76ea4d80dfdf530921d54060fac3647c9ac by Leslie Zhai.
Committed on 03/08/2017 at 08:38.
Pushed by lesliezhai into branch 'master'.

Prepare for big structural change.

M  +2    -2    src/k3bsystemproblemdialog.cpp

https://commits.kde.org/k3b/4a6aa76ea4d80dfdf530921d54060fac3647c9ac

Hi,

> https://cgit.kde.org/k3b.git/commit/?id=4a6aa76ea4d80dfdf530921d54060fac3647c9ac

The commit message is quite misleading. I already thought you'd go
full speed ahead without investigating the existing tasks of K3B
whether they can be represented in the way of my idea.
(I'd expect hours of code digging before this is clear.)

---------------------------------------------------------------------

For the non-quarrel aspect, which we always have to consider:
It seems unwise to say to the user that cdrskin is "better" than cdrecord.
Joerg Schilling could raise protest and it would be not easy to defeat
any possible point he could make. I was once his user. Since a few years
he has to accept me as peer - reluctantly. (German language readers
may look at https://forum.ubuntuusers.de/topic/k3b-brennt-keine-audio-cd-2/2/
where we quite nearly cooperated to find the reason why Xfburn worked and
K3B did not. It was an interesting ride.)

So how about (after due check whether it is really true in the context
of K3B):

  "Cdrskin can substitute for cdrecord with data and audio CD,
   and for growisofs with DVD and BD."

  "Consider to install the libburn and cdrskin packages."

---------------------------------------------------------------------

Further, the test for cdrecord and the test for cdrskin should both
set a local flag which indicates that a program with cdrecord's
mainstream options interface is available.
The tests for cdrecord should then preliminarily report their problems
as NON_CRITICAL.

If the new local flag is not set after the burn program tests, then K3B
should issue a CRITICAL message which tells that neither cdrecord nor
cdrskin are available for use by K3B.

---------------------------------------------------------------------

A similar situation lurks between growisofs and cdrskin.
The lack of growisofs should only be CRITICAl if not cdrskin can
substitute by its cdrecord-ish options interface.
cdrskin can substitute if it is available and if K3B is ready to use
it on DVD and BD by cdrecord-ish options.

cdrskin by modes of its option "blank=" can perform the tasks of
"dvd+rw-format": Formatting of DVD-RW, DVD+RW, DVD-RAM, BD-R, BD-RE.
Deformatting of DVD-RW.
But that would first have to be implemented in K3B, before availability
of cdrskin could make the lack of dvd+rw-format NON_CRITICAL.
(See man cdrskin or ask me for translating dvd+rw-format options to
 cdrskin blank modes.)


Have a nice day :)

Thomas

Git commit a3b8df01582085729d36f4a068e8f592179f95db by Leslie Zhai.
Committed on 04/08/2017 at 01:18.
Pushed by lesliezhai into branch 'master'.

Fix complains about missing cdrskin at start up before big structural change.

M  +3    -2    src/k3bsystemproblemdialog.cpp

https://commits.kde.org/k3b/a3b8df01582085729d36f4a068e8f592179f95db

*** Bug 385305 has been marked as a duplicate of this bug. ***

*** Bug 389423 has been marked as a duplicate of this bug. ***

This bug has disappeared with time