Summary: | app-cdr/cdrtools - version bump + additional questions and changes regarding the ebuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Pielmeier <billie> |
Component: | New packages | Assignee: | Gentoo Optical Media project <media-optical> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | andrey.vul, fauli, pva, T.Maguin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
cdrtools-2.01.01_alpha42.diff
cdrtools-2.01.01_alpha45.diff cdrtools-2.01.01_alpha47.diff cdrtools-2.01.01_alpha48.diff cdrtools-2.01.01_alpha50.diff |
Description
Daniel Pielmeier
2008-07-06 12:19:39 UTC
Created attachment 159694 [details, diff]
cdrtools-2.01.01_alpha42.diff
(In reply to comment #0) > Why is cdrkit the default for virtual/cdrtools at least in > profiles/base/virtuals in other profiles it is sometimes cdrtools sometimes > cdrkit? Is it because of the many bugs requesting the installation of cdrtools > suid root or the infamous license issue? cdrkit/cdrkit-1.1.8.ebuild:KEYWORDS="~alpha ~amd64 ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd" cdrtools/cdrtools-2.01.01_alpha42.ebuild:KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86" Is one of the main reasons...and yes I think pylon took cdrkit as default because he hoped cdrkit would become "better" than cdrtools because of all above reasons. media-optical, maybe we introduce a new-style virtual to centralise it? I can do that, if you give your ok and what about sending our patches upstream for cdrtools? (In reply to comment #0) > /usr/include/scg/ is completely missing in the default installation though it > is really needed and should go to /usr/include/scg/ according to the author of > cdrtools. Is this the reason why the default "make install" is not used, which > I am also curios about? According to the author of cdrtools, there was a makefile missing and thus so the libscg headers got not installed. I guess this will be fixed in the next version! (In reply to comment #0) > There are binaries (btcflash,isodebug,scgcheck,scgskeleton) which are not > installed in the gentoo installation I don't know whether this is intentionally > or not. By the way the firmware flash utility for the BTC DRW1008 DVD+/-RW recorder btcflash is also included in dvd+rw-tools but is not built and installed by default. (In reply to comment #0) > Under lib in the default installation there is a profiled and a siconv > directory. Are this Unicode translation tables under siconv not needed in > Gentoo? I am curios about the meaning of the profiled directory. Why is it > there? I mean the contents are the same as in lib! In cdrtools 2.01.01a28 libsiconv has been introduced to replace libunls. lisiconv needs the character translation tables in/usr/lib/siconv. [1] ftp://ftp.berlios.de/pub/cdrecord/alpha/AN-2.01.01a28 I've been wanting to move virtual/cdrtools to a new style virtual for some time now, so that cdrtools is the default. As for the flashing utility, need to check what's the difference between version in dvd+rw-tools, and where is it originally coming from and install the latest / most working version, add an elog to another.. "foo was not built, please install bar to get it." As for rest of the changes, they look good to me.. Will try to get this done by tomorrow with _alpha43 bump. (In reply to comment #6) > As for rest of the changes, they look good to me.. Will try to get this done by > tomorrow with _alpha43 bump. Thanks for taking care of this bug. Any comments regarding the "Unicode translation tables" and the different include structure? For the flashing utility it looks like the one from cdrtools is more recent as it has last been edited 13.06.2008 while the last change from dvd+rw-tools was 30.04.2004. (In reply to comment #6) > As for rest of the changes, they look good to me.. Will try to get this done by tomorrow with _alpha43 bump. In the meantime 2.01.01a44 and 2.01.01a45-pre got out. There were changes in the build system and the ebuid does not work anymore. Haven't figured out the reasons until now. One change was that there are no symlinks anymore in RULES and they are now created by the build system. In 2.01.01a44 the symlinks were not created at all, this is fixed in 2.01.01a45-pre. I verified this but did no further testing. _alpha43 works fine though. I think I got 2.01.01a45-pre working now. The main thing was that 2.01.01a44/2.01.01a45-pre failed with parallel build enabled. I don't know why so I disabled this in src_compile()! I also changed some other things: I added various "|| die" because the recent changes showed that they are really useful. src_unpack() I also added an additional sed in libfind as there where some /opt/schily traces. The creation of the symlinks is now done automatically so I removed this part. src_compile() There were some messages about "-pg and -fomit-frame-pointer are incompatible" so I added "filter flags -fomit-frame-pointer". I will attach a diff from alpha43 to alpha45-pre. Created attachment 162383 [details, diff]
cdrtools-2.01.01_alpha45.diff
Differences from alpha43 to alpha45-pre. alpha42 and alpha43 are identically.
cdrtools-2.01.01_alpha46 works without changes to cdrtools-2.01.01_alpha45 Your ebuild compiles fine with a46 here (x86). asneeded-patch is not necessary here to build mkisofs. Created attachment 164074 [details, diff]
cdrtools-2.01.01_alpha47.diff
cdrtools-2.01.01_alpha47 is out and works without changes to alpha46. I have attached a diff between alpha47 and the ebuild currently in tree (alpha42) for convenience.
Just FYI cdrtools-2.01.01_alpha48 works without changes to the latest diff for alpha47. Created attachment 165505 [details, diff] cdrtools-2.01.01_alpha48.diff (In reply to comment #14) > Your ebuild compiles fine with a46 here (x86). > asneeded-patch is not necessary here to build mkisofs. > I checked this and it is not needed here too, so I have removed it from the ebuild. I am aware of bug #65640, but maybe this thinking has changed in the meantime. Are there any objections on pulling in smake to build cdrtools with it. I know there is no other software in the tree that will benefit from this new build system besides probably star, but cdrtools is optimized to build with it so why not using it. Plus by using smake we can finally get rid of this warnings patch too. I know it is not always easy to get along with upstream oddities, but I think cooperation has to start somewhere. At least if there are build problems there is no way to put the blame on gnu make any longer. If I can allocate some time I can try to make an ebuild for for smake and integrate it in the cdrtools ebuild. Created attachment 166561 [details, diff]
cdrtools-2.01.01_alpha50.diff
New alpha 50 is out.
This diff now also replaces /opt/schily in the manpages and add die to the doman calls.
*** Bug 238824 has been marked as a duplicate of this bug. *** +*cdrtools-2.01.01_alpha50 (27 Sep 2008) + + 27 Sep 2008; Peter Alfredsen <loki_val@gentoo.org> + +files/cdrtools-2.01.01_alpha50-asneeded.patch, + +cdrtools-2.01.01_alpha50.ebuild: + Bump, fixing bug #230940 and bug #234537. Major rewrite to take advantage + of built-in make system. + I decided to scrap most of the old stuff and just use the make system that's there and scrape off the things we didn't want. |