FS#46114 - [cdrkit] upstream (website?) dead

Attached to Project: Arch Linux
Opened by Sebastiaan Lokhorst (lonaowna) - Wednesday, 26 August 2015, 17:00 GMT
Last edited by Jan de Groot (JGC) - Sunday, 22 January 2017, 19:03 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

The upstream website cdrkit.org is dead. It is impossible to get the source, and the website seems to be down for almost a year now.[1]
I'm not really familiar with the project, so I don't know if it has moved or the project is really dead.

In any case, it would be nice to be able to build the package myself, so if there is no alternative upstream location available and assuming we will keep offering the package, could we host the source ourselves?

[1] http://web.archive.org/web/*/http://www.cdrkit.org/
This task depends upon

Closed by  Jan de Groot (JGC)
Sunday, 22 January 2017, 19:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  cdrkit removed
Comment by Sebastiaan Lokhorst (lonaowna) - Wednesday, 26 August 2015, 17:54 GMT
After doing some more research, it seems that cdrtools is the better alternative which is maintained. Can't we move that to [extra] and just drop cdrkit?
Comment by Matthias Dienstbier (fs4000) - Thursday, 27 August 2015, 09:08 GMT
See https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy

I think we should try cdrskin from libburn as a cdrecord replacement. But how do the other distributions handle this currently?
Comment by Sebastiaan Lokhorst (lonaowna) - Thursday, 27 August 2015, 09:28 GMT
About cdrtools: I don't see a problem since we already ship the cdrtools package in the official repositories. Apparently the license doesn't prohibit that. I think the "issues" with the license are greatly exaggerated.

But, if libburn/cdrskin is equal or better, then I can see why that would be preferable, circumventing the potential issues completely.
Comment by Jan de Groot (JGC) - Friday, 28 August 2015, 12:08 GMT
cdrtools was replaced by cdrkit because of license conflicts (GPL/CDDL doesn't mix very well though Joerg Schilling claims it does). The GPL requires that the build system is GPL also, but in case of cdrtools the build system is partially CDDL.

Having cdrtools in community nullifies the whole reason why cdrkit was packaged in the first place.

I don't have experience with cdrskin, but looking at the cdrkit debacle (tonnes of bugs, no fixes, no maintenance) I don't like going for an emulated or forked version of such a common tool as cdrecord/mkisofs.

IMHO we should just drop cdrkit and package cdrecord instead. If there's any real license problem here Joerg should deal with it.
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 28 August 2015, 14:53 GMT
@JGC: I completely agree.
I'm not sure about cdrskin either, but it's always good to have an alternative (and we already package it anyway).
Comment by Loui Chang (louipc) - Saturday, 16 January 2016, 20:42 GMT
Yeah. Remove cdrkit. cdrskin looks like it would be the new alternative, but cdrtools should be the first choice.
Comment by roqz (roqz) - Saturday, 30 January 2016, 04:58 GMT
I just lost a couple of BD-R DL 50GB discs (which aren't cents-cheap) due to using cdrkit and growisofs, found out on the third try that cdrtools works perfectly. Already added a note on the Optical drives wiki entry, and in the Forum about this adventure.

My recommendation: Drop cdrkit and put cdrtools back in place. It saves money and avoids frustrations.
Comment by Jens Adam (byte) - Tuesday, 05 April 2016, 13:03 GMT
*poke*
Comment by Alif (alive4ever) - Sunday, 19 June 2016, 16:57 GMT
This should be considered as a flaw in the Arch Linux, since there is no copy of source tarball in Arch Linux infrastructure.

Debian has a copy of upstream or modified-upstream saved as "*.orig.tar.*" file. RHEL and derivatives also have *.src.rpm files which includes upstream tarball and .spec file.

Learning from those big distribution, Arch Linux infrastructure should also have a copy of upstream source tarball to avoid being unable to rebuild (in case of C / C++ abi changes, etc) package just because of dead upstream website.

For now, it may be just fine to point to "http://httpredir.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11.orig.tar.gz" as cdrkit source.
Comment by Jens Adam (byte) - Sunday, 19 June 2016, 17:02 GMT
Or, as stated repeatedly, just remove the goddamm package altogether already. Less choice, less bugs.

Loading...