[opensuse-factory] K3b Version 2.9.90+git20160111.2358-11.7-x86_64 - packman) and ISO burning - openSUSE Factory

newer
[opensuse-factory] openblas build...

[opensuse-factory] K3b Version 2.9.90+git20160111.2358-11.7-x86_64 - packman) and ISO burning

older
[opensuse-factory] No Audio over...

ianseeks

17 Jul 2016 17 Jul '16

12:33

Hi For Info.... This version is screwed with regards to ISO burning, sticks at 0% trying to do the MD5 check. The version 2.0.3 in KDE Extra seems fine. Do you still create a bug for k3b in KDE bugs for a Packman version? Regards Ian -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160714) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Wolfgang Bauer

17 Jul 17 Jul

14:00

Am Sonntag, 17. Juli 2016, 13:33:36 schrieb ianseeks:

...

This version is screwed with regards to ISO burning, sticks at 0% trying to do the MD5 check.

The (unstable and unreleased) KF5 version of k3b (2.9.90) had a "porting bug" in regards to image file handling, that has been fixed recently. I told the Packman people about this fix, so it will hopefully be added soon to their package: http://lists.links2linux.de/pipermail/packman/2016-July/014553.html Some Packman packager already created a package with the fix in his home repo, this just has to be submitted back to the main package.

...

The version 2.0.3 in KDE Extra seems fine.

Yes. That's the last stable release, and it is KDE4 based. And it's also the only one that we (openSUSE) officially provide.

...

Do you still create a bug for k3b in KDE bugs for a Packman version?

Well, many of Packman's packages are actually maintained by openSUSE in OBS, the packages in Packman are just links (that may be built with additional features like more codec support). That's not the case with k3b though, the Packman maintainer(s) decided to rather provide unreleased development snapshots about 2 years ago, so reporting a bug about it in openSUSE's bugzilla is pointless. Packman does have their own bugtracker since years: http://bugs.links2linux.org/ And there is the Packman mailing list of course, see http://packman.links2linux.de/help If (like in this case) it is a bug in k3b itself, not the packaging, it should rather be reported to KDE's bugzilla though, http://bugs.kde.org/. In this case it makes no sense to report it again, unless you still have a problem with the fixed package. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

14:15

On Sunday, 17 July 2016 16:00:50 BST Wolfgang Bauer wrote:

...

Am Sonntag, 17. Juli 2016, 13:33:36 schrieb ianseeks:

...
This version is screwed with regards to ISO burning, sticks at 0% trying to do the MD5 check.

The (unstable and unreleased) KF5 version of k3b (2.9.90) had a "porting bug" in regards to image file handling, that has been fixed recently.

I told the Packman people about this fix, so it will hopefully be added soon to their package: http://lists.links2linux.de/pipermail/packman/2016-July/014553.html

Some Packman packager already created a package with the fix in his home repo, this just has to be submitted back to the main package.

...
The version 2.0.3 in KDE Extra seems fine.

Yes. That's the last stable release, and it is KDE4 based. And it's also the only one that we (openSUSE) officially provide.

...
Do you still create a bug for k3b in KDE bugs for a Packman version?

Well, many of Packman's packages are actually maintained by openSUSE in OBS, the packages in Packman are just links (that may be built with additional features like more codec support).

That's not the case with k3b though, the Packman maintainer(s) decided to rather provide unreleased development snapshots about 2 years ago, so reporting a bug about it in openSUSE's bugzilla is pointless.

Packman does have their own bugtracker since years: http://bugs.links2linux.org/ And there is the Packman mailing list of course, see http://packman.links2linux.de/help

If (like in this case) it is a bug in k3b itself, not the packaging, it should rather be reported to KDE's bugzilla though, http://bugs.kde.org/.

In this case it makes no sense to report it again, unless you still have a problem with the fixed package.

Kind Regards, Wolfgang Thanks for the detailed reply.

-- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160714) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

18:34

On Sunday, 17 July 2016 16:00:50 BST Wolfgang Bauer wrote:

...

Am Sonntag, 17. Juli 2016, 13:33:36 schrieb ianseeks:

...
This version is screwed with regards to ISO burning, sticks at 0% trying to do the MD5 check.

The (unstable and unreleased) KF5 version of k3b (2.9.90) had a "porting bug" in regards to image file handling, that has been fixed recently.

I told the Packman people about this fix, so it will hopefully be added soon to their package: http://lists.links2linux.de/pipermail/packman/2016-July/014553.html

Some Packman packager already created a package with the fix in his home repo, this just has to be submitted back to the main package.

...
The version 2.0.3 in KDE Extra seems fine.

Yes. That's the last stable release, and it is KDE4 based. And it's also the only one that we (openSUSE) officially provide.

...
Do you still create a bug for k3b in KDE bugs for a Packman version?

Well, many of Packman's packages are actually maintained by openSUSE in OBS, the packages in Packman are just links (that may be built with additional features like more codec support).

That's not the case with k3b though, the Packman maintainer(s) decided to rather provide unreleased development snapshots about 2 years ago, so reporting a bug about it in openSUSE's bugzilla is pointless.

Packman does have their own bugtracker since years: http://bugs.links2linux.org/ And there is the Packman mailing list of course, see http://packman.links2linux.de/help

If (like in this case) it is a bug in k3b itself, not the packaging, it should rather be reported to KDE's bugzilla though, http://bugs.kde.org/.

In this case it makes no sense to report it again, unless you still have a problem with the fixed package.

Kind Regards, Wolfgang

Seems i spoke too soon. I've tried all versions open to me via repos and all iso burns fail at about 98% (except for v2.9 which doesn;t start) V 2.0.3-11.1-x86_64 from repo-oss V2.0.3-59.2-x86_64 from KDE Extra There is no error reported in the debug report. Has anyone else used any of these versions successfully recently? Regards Ian -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160714) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

18 Jul 18 Jul

09:42

Am Sonntag, 17. Juli 2016, 19:34:02 schrieb ianseeks:

...

Seems i spoke too soon. I've tried all versions open to me via repos and all iso burns fail at about 98% (except for v2.9 which doesn;t start) V 2.0.3-11.1-x86_64 from repo-oss V2.0.3-59.2-x86_64 from KDE Extra There is no error reported in the debug report.

k3b doesn't do the actual burning itself, it uses other tools for that (cdrecord or wodim/cdrkit). Try to install cdrecord instead of wodim (which is still installed by default), maybe that works better for you. It might also be a problem with the used CD though (scratched/dirty surface, incompatibility with your burner, ...) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

10:56

On Monday, 18 July 2016 11:42:52 BST Wolfgang Bauer wrote:

...

Am Sonntag, 17. Juli 2016, 19:34:02 schrieb ianseeks:

...
Seems i spoke too soon. I've tried all versions open to me via repos and all iso burns fail at about 98% (except for v2.9 which doesn;t start) V 2.0.3-11.1-x86_64 from repo-oss V2.0.3-59.2-x86_64 from KDE Extra There is no error reported in the debug report.

k3b doesn't do the actual burning itself, it uses other tools for that (cdrecord or wodim/cdrkit). Try to install cdrecord instead of wodim (which is still installed by default), maybe that works better for you.

It might also be a problem with the used CD though (scratched/dirty surface, incompatibility with your burner, ...)

Kind Regards, Wolfgang I downloaded another ISO - leap 42.1 and that burnt okay. I am assuming that if the downloaded ISO passes the md5 check, it should be a good iso. The one i'm failing with is Knoppix 7.6 and i've never known that to fail to burn. I was going to go out and buy some new DVD-Rs as i've had this stack a long time and its nearly empty especially after failing to burn about 8 yesterday.

Thanks for the info, i'll try cdrecord from the cli in the meantime -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160715) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

16:15

Am Montag, 18. Juli 2016, 11:56:51 schrieb ianseeks:

...

I downloaded another ISO - leap 42.1 and that burnt okay. I am assuming that if the downloaded ISO passes the md5 check, it should be a good iso. The one i'm failing with is Knoppix 7.6 and i've never known that to fail to burn.

That shouldn't really depend on the ISO though (unless it is too large to fit onto the CD/DVD... ;-) ). An ISO file is just a 1:1 copy of a CD/DVD, there is no special "format". And even if the md5 checksum is wrong, the burning shouldn't fail. Burning just means writing the image back to a CD/DVD 1:1. If the image is broken, the resulting CD/DVD will be broken. But burning it should still succeed.

...

Thanks for the info, i'll try cdrecord from the cli in the meantime

I think you misunderstood me. k3b does use cdrecord or wodim (cdrkit) for the actual burning (whichever is installed, it prefers cdrecord if both are there). But as cdrecord is actively developed and wodim not (since years), you may experience a bug/problem in wodim that is fixed in cdrecord. So I wanted to suggest that you try to install cdrecord if you are using wodim currently, maybe burning would succeed with k3b then. But if you were able to burn other ISOs, that's probably not the reason... Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

18:58

On Monday, 18 July 2016 18:15:40 BST Wolfgang Bauer wrote:

...

Am Montag, 18. Juli 2016, 11:56:51 schrieb ianseeks:

...
I downloaded another ISO - leap 42.1 and that burnt okay. I am assuming that if the downloaded ISO passes the md5 check, it should be a good iso. The one i'm failing with is Knoppix 7.6 and i've never known that to fail to burn.

That shouldn't really depend on the ISO though (unless it is too large to fit onto the CD/DVD... ;-) ). An ISO file is just a 1:1 copy of a CD/DVD, there is no special "format". And even if the md5 checksum is wrong, the burning shouldn't fail.

Burning just means writing the image back to a CD/DVD 1:1. If the image is broken, the resulting CD/DVD will be broken. But burning it should still succeed.

...
Thanks for the info, i'll try cdrecord from the cli in the meantime

I think you misunderstood me. k3b does use cdrecord or wodim (cdrkit) for the actual burning (whichever is installed, it prefers cdrecord if both are there).

I probably did :o) The k3b i've got installed is using wodim 1.1.11, so I did a "find" for wodim and cdrecord and they both are in /usr/bin.

...

But as cdrecord is actively developed and wodim not (since years), you may experience a bug/problem in wodim that is fixed in cdrecord.

Maybe time for wodim to deleted from the repos - not sure where it came from, i guess it might have been installed with the packman 2.9 version.

...

So I wanted to suggest that you try to install cdrecord if you are using wodim currently, maybe burning would succeed with k3b then.

I launched yast to check what version of cdrecord was installed and yast showed it as not installed. I then installed it and it brought in a few related dependencies and now k3b working as it did before. Thanks for the heads up and explanation.

...

But if you were able to burn other ISOs, that's probably not the reason...

...

Kind Regards, Wolfgang

-- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160715) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

19:29

Am Montag, 18. Juli 2016, 19:58:25 schrieb ianseeks:

...

...
I think you misunderstood me. k3b does use cdrecord or wodim (cdrkit) for the actual burning (whichever is installed, it prefers cdrecord if both are there).

I probably did :o) The k3b i've got installed is using wodim 1.1.11, so I did a "find" for wodim and cdrecord and they both are in /usr/bin.

On a default installation, cdrecord is just a symlink to wodim for compatibility reasons (that symlink is part of the package cdrkit-cdrtools- compat). To use the real cdrecord, you have to install it explicitly (which causes cdrkit-cdrtools-compat to be uninstalled).

...

Maybe time for wodim to deleted from the repos - not sure where it came from, i guess it might have been installed with the packman 2.9 version.

No. It is being installed by default since years. cdrkit (including wodim) was created based on an old cdrtools (cdrecord) version (by Debian IIANM), because there were assumed license problems with cdrtools. openSUSE dropped cdrtools and replaced them with cdrkit as well back then. Nowadays, cdrtools is again part of the distribution (since 13.2 I think), but unless this has changed recently, cdrkit is still installed by default. But cdrkit hasn't really been improved since years (unlike cdrtools), and according to cdrtools' author even contains severe bugs (I cannot and don't want to comment on that though). You might want to search the Internet for further discussions/explanations if you are interested... But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi still requires it for some reason AIUI.

...

I launched yast to check what version of cdrecord was installed and yast showed it as not installed.

So you did in fact use wodim/cdrkit.

...

I then installed it and it brought in a few related dependencies and now k3b working as it did before.

So your problem is solved now? ;-) Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

19 Jul 19 Jul

08:06

On Monday, 18 July 2016 21:29:50 BST Wolfgang Bauer wrote:

...

Am Montag, 18. Juli 2016, 19:58:25 schrieb ianseeks:

...
...
I think you misunderstood me. k3b does use cdrecord or wodim (cdrkit) for the actual burning (whichever is installed, it prefers cdrecord if both are there).

I probably did :o) The k3b i've got installed is using wodim 1.1.11, so I did a "find" for wodim and cdrecord and they both are in /usr/bin.

On a default installation, cdrecord is just a symlink to wodim for compatibility reasons (that symlink is part of the package cdrkit-cdrtools- compat).

To use the real cdrecord, you have to install it explicitly (which causes cdrkit-cdrtools-compat to be uninstalled).

...
Maybe time for wodim to deleted from the repos - not sure where it came from, i guess it might have been installed with the packman 2.9 version.

No. It is being installed by default since years. cdrkit (including wodim) was created based on an old cdrtools (cdrecord) version (by Debian IIANM), because there were assumed license problems with cdrtools. openSUSE dropped cdrtools and replaced them with cdrkit as well back then. Ok, thanks for the explanation

...

Nowadays, cdrtools is again part of the distribution (since 13.2 I think), but unless this has changed recently, cdrkit is still installed by default.

But cdrkit hasn't really been improved since years (unlike cdrtools), and according to cdrtools' author even contains severe bugs (I cannot and don't want to comment on that though).

You might want to search the Internet for further discussions/explanations if you are interested...

But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi still requires it for some reason AIUI. Maybe they need to be prompted to drop it or fix it.

...

...
I launched yast to check what version of cdrecord was installed and yast showed it as not installed.

So you did in fact use wodim/cdrkit. I went from 13.1 to tumbleweed and i never had a burn fail prior to tumbleweed, i think this is the first burns i've done since tumbleweed.

...

...
I then installed it and it brought in a few related dependencies and now k3b working as it did before.

So your problem is solved now? ;-) It certainly seems so, thanks again.

Kind Regards, Wolfgang

Joerg Schilling

10:15

ianseeks wrote:

...

...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi still requires it for some reason AIUI. Maybe they need to be prompted to drop it or fix it.

IIRC, there was such a discussion, but some people did fear problems from front ends that have been patched by Debian and others in order to support wodim. Maybe it is time to rethink this decision.

...

...
...
I launched yast to check what version of cdrecord was installed and yast showed it as not installed.

So you did in fact use wodim/cdrkit. I went from 13.1 to tumbleweed and i never had a burn fail prior to tumbleweed, i think this is the first burns i've done since tumbleweed.

The problem with wodim is that it sometimes hangs, works in many cases with CDs, fails with a rate of aprox. 50% with DVDs and does not support BluRays at all. The problem with genisoimage is that it inserts bugs in the filesystem that are not visible for most people because they do not look in dept at the results. There may be a complete failure in the future when someone fixes the ISO9660 filesystem driver in Linux. Mkisofs fixed dozens of bugs in August 2006 - which is more than 2 years after Debian stopped importing original code. BTW: The bugs in that software exist since May 2004, when Debian started their fork by inserting bad code. They did this by using the original program names and tried to hide the fact that they did not distribute the original software anymore. After it turned out that they are not willing to cooperate nor to fix their bugs, they have been explicitely disallowed to use the original names. This resulted in the new names introduced around September 2006. Debian however claimed that they just created the fork at that time even though it offeres the same set of Debian specific bugs as you can see in the fork (using the original names) from around Autumn 2004 already. Given that we are talking about more than 50 Debian specific bugs, this is a strongly unique indication. P.S. in September 2004, I have been asked by Roy Fielding from the Apache foundation what happened and after I explained that, he confirmed that similar problems exist bewteen Apache and Debian. So what you see with cdrtools looks like a typical social battle initated by Debian. Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

11:33

On Tuesday, 19 July 2016 12:15:08 BST Joerg Schilling wrote:

...

ianseeks wrote:

...
...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi still requires it for some reason AIUI.

Maybe they need to be prompted to drop it or fix it.

IIRC, there was such a discussion, but some people did fear problems from front ends that have been patched by Debian and others in order to support wodim.

Maybe it is time to rethink this decision.

It does seem silly to have software around that doesn't work reliably

...

...
...
...
I launched yast to check what version of cdrecord was installed and yast showed it as not installed.

So you did in fact use wodim/cdrkit.

I went from 13.1 to tumbleweed and i never had a burn fail prior to tumbleweed, i think this is the first burns i've done since tumbleweed.

The problem with wodim is that it sometimes hangs, works in many cases with CDs, fails with a rate of aprox. 50% with DVDs and does not support BluRays at all.

The problem with genisoimage is that it inserts bugs in the filesystem that are not visible for most people because they do not look in dept at the results. There may be a complete failure in the future when someone fixes the ISO9660 filesystem driver in Linux. Mkisofs fixed dozens of bugs in August 2006 - which is more than 2 years after Debian stopped importing original code.

BTW: The bugs in that software exist since May 2004, when Debian started their fork by inserting bad code. They did this by using the original program names and tried to hide the fact that they did not distribute the original software anymore.

After it turned out that they are not willing to cooperate nor to fix their bugs, they have been explicitely disallowed to use the original names. This resulted in the new names introduced around September 2006. Debian however claimed that they just created the fork at that time even though it offeres the same set of Debian specific bugs as you can see in the fork (using the original names) from around Autumn 2004 already. Given that we are talking about more than 50 Debian specific bugs, this is a strongly unique indication.

P.S. in September 2004, I have been asked by Roy Fielding from the Apache foundation what happened and after I explained that, he confirmed that similar problems exist bewteen Apache and Debian. So what you see with cdrtools looks like a typical social battle initated by Debian.

Jörg

Thanks for the historical context, wonder if devuan have taken it on :o) -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160716) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dave Plater

20 Jul 20 Jul

12:53

On 19/07/2016 10:06, ianseeks wrote:

...

...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi

...
still requires it for some reason AIUI. Maybe they need to be prompted to drop it or fix it.

...
...
...
...
Your best bet is to zypper in cdrtools, that will remove cdrkit-cdrtools-compat and replace all symlinks with the correct files. The last hard dependency, kiwi, on cdrkit-cdrtools-compat has been removed and as soon as I have time patterns-openSUSE will install cdrtools. It will be fixed in Leap:42.2 as well. Best regards Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

15:55

On Wednesday, 20 July 2016 14:53:02 BST Dave Plater wrote:

...

On 19/07/2016 10:06, ianseeks wrote:

...
...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi

...
still requires it for some reason AIUI.

Maybe they need to be prompted to drop it or fix it.

Your best bet is to zypper in cdrtools, that will remove cdrkit-cdrtools-compat and replace all symlinks with the correct files. The last hard dependency, kiwi, on cdrkit-cdrtools-compat has been removed and as soon as I have time patterns-openSUSE will install cdrtools. It will be fixed in Leap:42.2 as well. Best regards Dave P Thanks dave. I used Yast to get cdrecord and cdrtools and thats all i did for it to start working again

-- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.1 Kernel: 4.6.3-1-default "openSUSE Tumbleweed (20160716) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Yamaban

18:56

New subject: [opensuse-factory] Re: K3b Version 2.9.90+git20160111.2358-11.7-x86_64 - packman) and ISO burning

On Wed, 20 Jul 2016 14:53, Dave Plater wrote:

...

On 19/07/2016 10:06, ianseeks wrote:

...
...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi

...
still requires it for some reason AIUI. Maybe they need to be prompted to drop it or fix it.

...
...
...
...
Your best bet is to zypper in cdrtools, that will remove cdrkit-cdrtools-compat and replace all symlinks with the correct files. The last hard dependency, kiwi, on cdrkit-cdrtools-compat has been removed and as soon as I have time patterns-openSUSE will install cdrtools. It will be fixed in Leap:42.2 as well. Best regards Dave P

"cdrkit-cdrtools-compat" and "wodim" is only half of the trouble origin. "genisoimage" is the other half, buggy as hell and the images it creates are only fit for the trash. For example "file-roller" in Leap:42.1 depends on "genisoimage", could that also be fixed for Leap:42.2 / TW (using mkisofs as replacement)? I'm just asking, no pressure from me, but it would be a nice betterment. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Joerg Schilling

21 Jul 21 Jul

08:17

New subject: [opensuse-factory] Re: K3b Version 2.9.90+git20160111.2358-11.7-x86_64 - packman) and ISO burning

Yamaban wrote:

...

"genisoimage" is the other half, buggy as hell and the images it creates are only fit for the trash.

This is well known :-( Testing discovered many bugs in Summer 2006 that have been fixed in August 2006 and Debian even added own Debian specific new bugs.

...

For example "file-roller" in Leap:42.1 depends on "genisoimage", could that also be fixed for Leap:42.2 / TW (using mkisofs as replacement)?

I'm just asking, no pressure from me, but it would be a nice betterment.

Do you know why there might be problems? genisoimage mainly was tied to the state from Summer 2004 by Debian. There was a big problem: The options -H/-L/-P from the old mkisofs have been deprecated long ago, but Debian fetched a version before they have been finally disabled for another (POSIX) purpose that will soon be enabled, since aprox. 15 years have passed since deprecating them. The bas news is that Debian not just stayed with the old mkisofs source but removed a warning that explains that these options are deprecated since a long time. So frontends may use these options.... Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Werner Flamme

08:38

Dave Plater [20.07.2016 14:53]:

...

On 19/07/2016 10:06, ianseeks wrote:

...
...
But yes, it would probably be a good idea to drop cdrkit IMHO, though kiwi

...
still requires it for some reason AIUI. Maybe they need to be prompted to drop it or fix it.

...
...
...
...
Your best bet is to zypper in cdrtools, that will remove cdrkit-cdrtools-compat and replace all symlinks with the correct files. The last hard dependency, kiwi, on cdrkit-cdrtools-compat has been removed and as soon as I have time patterns-openSUSE will install cdrtools. It will be fixed in Leap:42.2 as well. Best regards Dave P

When I execute "zypper in cdrtools", I get some other packages as well. Something seems to be wrong with the cdrecord package: (6/8) Installing: cdrecord-3.01-1.5.x86_64 .................................................................................................................................................................[done] Additional rpm output: setting /usr/bin/cdrecord to root:root 0755 "= cap_ipc_lock,cap_sys_rawio,cap_sys_nice,cap_sys_resource+ep". (wrong missing capabilities) Has somone else seen this? How might it been solved, except by filing a bug report? Regards, Werner --

Joerg Schilling

08:41

Werner Flamme wrote:

...

When I execute "zypper in cdrtools", I get some other packages as well. Something seems to be wrong with the cdrecord package:

(6/8) Installing: cdrecord-3.01-1.5.x86_64 .................................................................................................................................................................[done] Additional rpm output: setting /usr/bin/cdrecord to root:root 0755 "= cap_ipc_lock,cap_sys_rawio,cap_sys_nice,cap_sys_resource+ep". (wrong missing capabilities)

The documented capability set is: setcap cap_sys_resource,cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_ipc_lock,cap_sys_rawio+ep /opt/schily/bin/cdrecord setcap cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_sys_rawio+ep /opt/schily/bin/cdda2wav setcap cap_dac_override,cap_sys_admin,cap_net_bind_service,cap_sys_rawio+ep /opt/schily/bin/readcd Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Werner Flamme

09:10

Joerg Schilling [21.07.2016 10:41]:

...

Werner Flamme wrote:

...
When I execute "zypper in cdrtools", I get some other packages as well. Something seems to be wrong with the cdrecord package:

(6/8) Installing: cdrecord-3.01-1.5.x86_64 .................................................................................................................................................................[done] Additional rpm output: setting /usr/bin/cdrecord to root:root 0755 "= cap_ipc_lock,cap_sys_rawio,cap_sys_nice,cap_sys_resource+ep". (wrong missing capabilities)

The documented capability set is:

setcap cap_sys_resource,cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_ipc_lock,cap_sys_rawio+ep /opt/schily/bin/cdrecord setcap cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_sys_rawio+ep /opt/schily/bin/cdda2wav setcap cap_dac_override,cap_sys_admin,cap_net_bind_service,cap_sys_rawio+ep /opt/schily/bin/readcd

Thank you, the commands work for the files in the packages (one line per command): # setcap cap_sys_resource,cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_ipc_lock,cap_sys_rawio+ep /usr/bin/cdrecord # setcap cap_dac_override,cap_sys_admin,cap_sys_nice,cap_net_bind_service,cap_sys_rawio+ep /usr/bin/cdda2wav # setcap cap_dac_override,cap_sys_admin,cap_net_bind_service,cap_sys_rawio+ep /usr/bin/readcd They are system packages, so they won't install to /opt/schily, I guess ;) So I'll file a bug report, since the package seems to have a wrong command inside. Hm, in the spec file https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/cdrtools/cdr... I see the caps (lines 58-60) written with = instead of +. Should this be changed? I am not familiar with the setcap program. Werner --

Rainer Klier

18 Jul 18 Jul

08:11

Am 2016-07-17 um 16:00 schrieb Wolfgang Bauer:

...

The (unstable and unreleased) KF5 version of k3b (2.9.90) had a "porting bug" in regards to image file handling, that has been fixed recently.

I told the Packman people about this fix, so it will hopefully be added soon to their package: http://lists.links2linux.de/pipermail/packman/2016-July/014553.html

Some Packman packager already created a package with the fix in his home repo, this just has to be submitted back to the main package.

until the fixed version is available in packman repo i use the following workaround: i installed the following packages which are made for leap 42.1: k3b-codecs-2.0.80+git20160102.1831-11.1.x86_64 k3b-2.0.80+git20160102.1831-11.1.x86_64 k3b-lang-2.0.80+git20160102.1831-11.1.noarch i downloaded them from packman repo for leap 42.1 and installed them manually. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | *DI Rainer Klier* Research & Development, Technical Sales Consultant Namirial GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

09:40

Am Montag, 18. Juli 2016, 10:11:22 schrieb Rainer Klier:

...

until the fixed version is available in packman repo i use the following workaround: i installed the following packages which are made for leap 42.1: k3b-codecs-2.0.80+git20160102.1831-11.1.x86_64 k3b-2.0.80+git20160102.1831-11.1.x86_64 k3b-lang-2.0.80+git20160102.1831-11.1.noarch

That's a development snapshot of the KDE4 version. Should work the same (or not) as 2.0.3. Of course the Packman version has the advantage that it does contain the mp3 plugin (in k3b-codecs). Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Rainer Klier

10:23

Am 2016-07-18 um 11:40 schrieb Wolfgang Bauer:

...

Am Montag, 18. Juli 2016, 10:11:22 schrieb Rainer Klier:

...

...
i installed the following packages which are made for leap 42.1: k3b-codecs-2.0.80+git20160102.1831-11.1.x86_64 k3b-2.0.80+git20160102.1831-11.1.x86_64 k3b-lang-2.0.80+git20160102.1831-11.1.noarch

That's a development snapshot of the KDE4 version. Should work the same (or not) as 2.0.3.

Of course the Packman version has the advantage that it does contain the mp3 plugin (in k3b-codecs).

that's why i use this as temporarily replacement. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* Research & Development, Technical Sales Consultant namirialLogo _________________________________________________________ Namirial GmbH Phone: +43 7229 88 0 60 - 758 | Mobile: +43 664 610 17 06 Haiderstraße 23 | 4052 Ansfelden | Austria Website: https://www.xyzmo.com/ Support: https://www.xyzmo.com/contact/support The sender of this email disclaims any intent to be bound hereby, except where the sender clearly and explicitly provides otherwise. namirialAd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Wolfgang Bauer

25 Jul 25 Jul

12:06

FYI, the (hopefully) fixed k3b package should be in the Packman repos by now. There has been a build problem with xine-lib (on which k3b depends) too which delayed this a bit further... Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

ianseeks

15:05

On Monday, 25 July 2016 14:06:46 BST Wolfgang Bauer wrote:

...

FYI, the (hopefully) fixed k3b package should be in the Packman repos by now.

There has been a build problem with xine-lib (on which k3b depends) too which delayed this a bit further...

Kind Regards, Wolfgang

Thanks for the update -- Qt: 5.6.1 KDE Frameworks: 5.24.0 kf5-config: 1.0 KDE Plasma: 5.7.2 Kernel: 4.6.4-1-default "openSUSE Tumbleweed (20160720) (x86_64)" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2838

Age (days ago)

2846

Last active (days ago)

List overview

Download

23 comments

7 participants

participants (7)

Dave Plater
ianseeks
Joerg Schilling
Rainer Klier
Werner Flamme
Wolfgang Bauer
Yamaban