To point out the obvious, the versioning and source availability for this package is more messy than for a typical package.
It may be worth considering changing the build script to build cdrtools instead.
This is what provides cdrkit on Arch Linux, and it seems to be more straightforward to build.
https://gitlab.archlinux.org/archlinux/packaging/packages/cdrtools/-/blob/3.02a09-6/PKGBUILD

It compiles successfully on my local machine, but when using GitHub CI, various problems mysteriously occur.

The CI is most likely running into cross compilation issues since it is building the package on a x86_64 host.
Whereas on your phone it is a "simple" native compilation.

OK, I have found the cause; it's libandroid-glob and libandroid-utimes, they do not link automatically.

Here

ld.lld: error: undefined symbol: glob
>>> referenced by scsihack.c
>>>               scsihack.c.o:(usalo_maxdma) in archive libusal/libusal.a
>>> referenced by scsihack.c
>>>               scsihack.c.o:(usalo_maxdma) in archive libusal/libusal.a

ld.lld: error: undefined symbol: globfree
>>> referenced by scsihack.c
>>>               scsihack.c.o:(usalo_maxdma) in archive libusal/libusal.a
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Yep that'd make sense.

Oh, I hate the shell script.

I still think you might wanna consider packaging the cdrtools version of cdrkit instead.
They seem to provide the same set of utilities but cdrtools seems to be more actively maintained.

However, it seems that cdrtools has a particularly large number of set*uid calls, making it difficult to modify.

cdrkit is still relatively less common

I'm not certain either version of the utilities would even work without root privileges.

set*uid is not supported on Android and will trigger EOSYSCALL

I'm not certain either version of the utilities would even work without root privileges.

Sure, my device doesn't have root access, but it can normally package an ISO.

Okay that's good.
Still not sure if we're gonna get it cross-compiling.

Okay that's good. Still not sure if we're gonna get it cross-compiling.

I'm trying. I hope it can successful build.

I found that this report description was referring to Debian, so I made some modifications.

@robertkirkman Do you think I should replace the 'report' description in the help information of all commands in cdrkit with my own email or with information directing users to submit issues to the termux-package repository?

@robertkirkman Do you think I should replace the 'report' description in the help information of all commands in cdrkit with my own email or with information directing users to submit issues to the termux-package repository?

Or keep it as it is

-        "\nReport problems to debburn-devel@lists.alioth.debian.org.\n"); 
 +        "\nReport problems to xingguangcuican666@foxmail.com or create issue on termux-packages repo and @xingguangcuican6666.\n");

Here

@robertkirkman Do you think I should replace the 'report' description in the help information of all commands in cdrkit with my own email or with information directing users to submit issues to the termux-package repository?

Please replace it with this kind of message:

"Report problems to https://github.com/termux/termux-packages/issues"

I don't think it is necessary to insert xingguangcuican666@foxmail.com, because issues should be publicly visible and not in private email.

OKay

I modified it

Ok nice, I am finished with the PR I mentioned before, and now I'm working on part of this other issue, and then after I finish that I will review this PR more.

• [Bug]: cinnamon doesn't start on Turnip devices without LIBGL_ALWAYS_SOFTWARE=1 #26772

Okay, I was just looking to see if there was anything else that could be optimized.

Okay, at least for now I don't think there's much left to optimize.

Hello?

Hello I will help more soon but I had just been working on other PRs and issues that happened I'm sorry for delay

Sorry to bother you. I will continue to wait for you.

To give an update, one of the things that is taking me so long is, I want to verify that the cdrecord command will actually work to burn a real CD-RW from a real Android-x86 device with CD-RW drive attached, but I am having some technical difficulties with setup before getting to the point I can actually test the cdrecord command,

do not worry I will eventually get it completely set up and I have all tools necessary to do so, but if you want to speed up the process then you can if you have access to such a device with that capability, you can also test and let me know what result you see. If you don't have access to such a device then don't worry, I do and I will eventually get completely set up and finish testing.

Okay, I don't have suitable equipment for testing, but I will try to conduct the test in a virtual machine. Thank you so much.

To add, I removed the remote SCSI functionality, as this feature is quite outdated and also causes some difficulties during compilation.

Alright, I did my best; the virtual CD-RW on the Android x86 virtual machine doesn't seem to work properly.

@xingguangcuican6666

Thank you for trying,

I can let you know that unfortunately, after setting up a functioning real Android-x86 device with a real physical CD-RW drive connected, I did test your version, and it is not able to control the real CD-RW drive. This occurs:

:/data/data/com.termux/files/home # wodim --version
Cdrecord-yelling-line-to-tell-frontends-to-use-it-like-version 2.01.01a03-dvd 
Wodim 1.1.11
Copyright (C) 2006 Cdrkit suite contributors
Based on works from Joerg Schilling, Copyright (C) 1995-2006, J. Schilling
:/data/data/com.termux/files/home # wodim -eject                                                                             
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/sr0
wodim: Cannot do inquiry for CD/DVD-Recorder.
Errno: 5 (I/O error), test unit ready scsi sendcmd: fatal error
CDB:  00 E0 00 00 00 00
cmd finished after 0.000s timeout 40s
255|:/data/data/com.termux/files/home # 

however, I do have very good news.

After 400 hours of work, I have separately created my own port of the wodim command to Termux which is able to successfully burn a https://dl-cdn.alpinelinux.org/alpine/v3.22/releases/x86_64/alpine-standard-3.22.2-x86_64.iso to a CD-RW disc directly from bare metal Android-x86 using only bionic libc without proot or chroot and then, when the CD-RW drive is selected during UEFI BIOS loading, that alpine-standard-3.22.2-x86_64.iso boots successfully to shell!

:/data/data/com.termux/files/home # wodim --version
Cdrecord-ProDVD-ProBD-Clone 3.02 2024/03/18 (x86_64-pc-linux-android) Copyright (C) 1995-2019 Joerg Schilling
:/data/data/com.termux/files/home # wodim -blank=fast                                                         
Cdrecord-ProDVD-ProBD-Clone 3.02 2024/03/18 (x86_64-pc-linux-android) Copyright (C) 1995-2019 Joerg Schilling
Linux sg driver version: 3.5.36
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
Using dev=2,0,0.
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   : 
Vendor_info    : 'hp      '
Identifikation : 'DVDRW GUD1N     '
Revision       : 'MD00'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE 
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
cdrecord: Warning: Cannot read drive buffer.
cdrecord: Warning: The DMA speed test has been skipped.
Starting to write CD/DVD/BD at speed 10 in real BLANK mode for single session.
Last chance to quit, starting real write    0 seconds. Operation starts.

My version is extremely different from the version that is in this PR.

I still have more work to do to adjust the code and try to cross-compile it. I have not cross-compiled it yet and it might be very difficult to do that.

If I am not able to cross-compile it successfully, I will put it in tur-on-device.

When I finish adjusting my version eventually, I will upload it and then you can help me test it if you would like. I hope that my version will be able to also do the tasks you need to use it for. I focused specifically on implementing and testing the wodim command, because I wanted to make sure that Burning CD on Android-x86 is possible, but my version does have the mkisofs command too, so hopefully it will work without a bug for you, once I send you my version.

Here is a preview of what my version looks like:

~/termux-packages $ ls packages/schilytools/
RULES_rules.shl.patch           ctags_Makefile.patch           rscsi.subpackage.sh
android-no-getdtablesize.patch  hdump_Makefile.patch           rscsi_rscsi.dfl.patch
android-no-getloadavg.patch     hdump_od.mk1.patch             sccs.subpackage.sh
android-no-hardlink.patch       libgetopt_getopt.mk3.patch     sccs_man_diffman.mk.patch
android-no-valloc.patch         libgetopt_getsubopt.mk3.patch  scgcheck_scgcheck.1.patch
bosh.subpackage.sh              libschily_error.mk3.patch      schilyutils.subpackage.sh
bsh_Makefile.man.patch          libschily_fexecve.mk3.patch    sh_Makefile.man.patch
bsh_Makefile.patch              libschily_fnmatch.mk3.patch    sh_Makefile.patch
btcflash_btcflash.1.patch       libschily_fprintf.mk3.patch    sh_jsh.1.patch
build.sh                        libschily_printf.mk3.patch     sh_jsh.mk1.patch
cal_Makefile.man.patch          libschily_sprintf.mk3.patch    sh_sh.1.patch
cal_Makefile.patch              libschily_strlen.mk3.patch     sh_tests_common_test-common.patch
calc_Makefile.man.patch         mt_Makefile.patch              smake.subpackage.sh
calc_Makefile.patch             obosh_obosh.1.patch            star.subpackage.sh
calltree-fix-setfd.patch        patch_patch.mk1.patch          star_Makefile.patch
cdrecord_README.rscsi.patch     pbosh_pbosh.1.patch            star_star.1.patch
cdrecord_cdrecord.1.patch       printf_Makefile.man.patch      sunpro_Make_bin_make_common_Makefile.man.patch
cdrecord_cdrecord.dfl.patch     printf_Makefile.patch          sunpro_Make_bin_make_common_Makefile.patch
cdrtools.subpackage.sh          readcd_readcd.1.patch          sunpro_Make_lib_bsd_src_Makefile.patch
compare_Makefile.man.patch      rmt_Makefile.dfl.patch         sunpromake.subpackage.sh
compare_Makefile.patch          rmt_Makefile.doc.patch         tartest.subpackage.sh
count_Makefile.man.patch        rmt_Makefile.man.patch         ved.subpackage.sh
count_Makefile.patch            rmt_Makefile.patch
~/termux-packages $ 

That's cool !

I'm really looking forward to its performance.

I think I should create a PR and then release only the CDRKit source code related to ISO building. Because it seems that the cdrkit I ported only works with programs that operate on ISO files.

My version is extremely different from the version that is in this PR.

I still have more work to do to adjust the code and try to cross-compile it. I have not cross-compiled it yet and it might be very difficult to do that.

If I am not able to cross-compile it successfully, I will put it in tur-on-device.

When I finish adjusting my version eventually, I will upload it and then you can help me test it if you would like. I hope that my version will be able to also do the tasks you need to use it for. I focused specifically on implementing and testing the wodim command, because I wanted to make sure that Burning CD on Android-x86 is possible, but my version does have the mkisofs command too, so hopefully it will work without a bug for you, once I send you my version.

Yes, I’d be happy to test it, but I only have a virtual machine. I can also help you see how to do it through cross-compiling.

To point out the obvious, the versioning and source availability for this package is more messy than for a typical package. It may be worth considering changing the build script to build cdrtools instead. This is what provides cdrkit on Arch Linux, and it seems to be more straightforward to build. https://gitlab.archlinux.org/archlinux/packaging/packages/cdrtools/-/blob/3.02a09-6/PKGBUILD

I am now able to provide a summarized response to this. As it has turned out,

• real cdrtools is completely not more straightforward to build - it is extremely convoluted and requires at least 40 patches
• on the other hand, real cdrtools is capable of connecting to a real CD-RW drive and perfoming CD rips and burns while running on bare metal Android-x86, while the cdrkit unfortunately does not seem to be able to

I feel that maximizing the functionality and use-cases of the package is a high priority, so I am going to continue to progress on real cdrtools to prepare it for uploading.

I tried to port cdrtools, but I found that the build system is unusual and cannot correctly find the compilation environment on Termux. I am currently recreating a fork and trying to build it using GitHub's full CI.

I tried to port cdrtools, but I found that the build system is unusual and cannot correctly find the compilation environment on Termux.

Yes, it is extremely difficult. but after a long time of working, I was able to successfully do it by applying dozens of patches and writing a long build.sh script. I also used a specific special version of the source code to start with before patching. Now that I have tested the result and I know that at least the wodim (aka cdrecord) command is working, I promise to upload it soon and show it, but I just need to organize my code and make final adjustments.

OK, I will wait for you.