I just made a new version of the kudzu-knoppix ebuild. Embedded profiles are not happy with NLS, so I added a nls IUSE. If this flag is unset (via /etc/make.conf or an embedded profile spec), a anti-nls patch is added. Kudzu offers a python module, but was not installed by default. Obviously, the python USE flag will install it. Finally, the minimal flag installs the same stuff as livecd plus updfstab just like the Knoppix auto-config port for Mandr* installs. Note that I am/was (I should rework on it) the maintainer of Mandr* port of the Knoppix auto-configuration system. I also changed the path for the module configuration file to /etc/modules.d/kudzu, so modules-update can manage it. Note that I am a newcomer when it comes to Gentoo ebuilds. Discussion is highly welcomed. There are also some FIXME comments inside the ebuild. Reproducible: Always Steps to Reproduce:
Created attachment 56196 [details, diff] The proposed new ebuild Another note I forgot: The "livecd" USE flag overrides the "minimal" USE flag and the "minimal" USE flag overrides the python USE flag (livecd > minimal > python > (none)). The nls flag is independent from the three others.
Created attachment 56197 [details, diff] Patch to disable NLS making embedded profiles happier
A couple things... I think it is very possible to link kudzu against uclibc and not require dietlibc, but it would need to be verified. I'm really not much of a kudzu expert. We really only use it for the livecd to use with hwsetup. Also, a "gentoo" init script for kudzu would be outstanding. It really shouldn't be hard to create one from the default one that follows the Gentoo standard for init scripts. The truth is that I honestly just have not had time to investigate it yet. One last thing, would these also apply to kudzu, as well as kudzu-knoppix?
>> I think it is very possible to link kudzu against uclibc and not require >> dietlibc, but it would need to be verified. I'm really not much of a kudzu >> expert. We really only use it for the livecd to use with hwsetup. Actually, you only need libkudzu for link hwsetup, not kudzu_loader. I don't know the purpose of the kudzu_loader library, which uses dietlibc only on x86 (according to Makefile and kudzu.spec). And about hwsetup, I made a patch which adds a command-line option to perform a very fast probing (skipping serial and PS/2 stuff, hence why it's an option). But that is another matter. >> Also, a "gentoo" init script for kudzu would be outstanding. See bug #61978 attchments. I might add it (will be merged on the live system only when USE neither contains livecd nor minimal). >> One last thing, would these also apply to kudzu, as well as kudzu-knoppix? I think so. The perl command has to be adjusted and patches have to be corrected, although.
Created attachment 56278 [details] Updated ebuild for NLS fixes, config files and ddcxinfo-knoppix This revised ebuild installs Gentoo-fied configuration files and removes the RH ones. It also uses a new version of the NLS removal patch, upon psm and solar recommendations (soon to be attached). I also added the ddcxinfo-knoppix utility from ddcxinfo-knoppix-0.6-5.tar.gz and put it into the ddcprobe directory. I had to remove vbe_ prefixes to make it build. It seems to work OK. I also tweaked its manual page. This patch is bit big for $FILESDIR with its 23.7 KiB. I added to requests for comments as FIXME inside the ebuild too. Please test on non-embedded systems with the nls USE flag set as well.
Created attachment 56279 [details, diff] Better NLS removal patch (with input from psm and solar)
Created attachment 56281 [details, diff] Patch adding ddcxinfo-knoppix into kudzu-knoppix
We actually have ddcxinfo-knoppix as a separate package already. Is there an advantage in including it or did you just not notice we already had it? I would prefer keeping it separate, as we use it on X-enabled LiveCD images, while still only using libkudzu from kudzu-knoppix.
There is source code duplication between kudzu-knoppix and ddcxinfo-knoppix. By putting ddcxinfo-knoppix into kudzu-knoppix, it can also benefit from bug fixes into the other files as Klaus Knopper and later the livecd herd move to a newer version of kudzu. But if you don't see no benefit, I don't mind keeping it for my overlay. But something that would be more relevant would be to include hwsetup, so we someones emerges kudzu-knoppix with the livecd USE flag, it installs hwsetup only, thus saving space. It's just to have fewer packages to handle.
Erratum: In paragraph 2, "so we someones" should be read as "so if someone"
We don't like to combine packages... it makes it easier to update them individually... I also don't want to combine ddcxinfo-knoppix simply because it doesn't work on non-x86 arches, whereas kudzu does.
Created attachment 56312 [details] Ebuild whithout the ddcxinfo-knoppix patch It is easy to remove. Looks like I will also fork kudzu for my own needs (and that will not be in the Portage tree). I mentionned other issues in the previous ebuild, like moving the configuration files from /etc/sysconfig to /etc/conf.d (ddcxinfo-knoppix, hwsetup and other Knoppix scripts must be updated accordingly). More importantly, the "kudzu" newt-based interface always does a segmentation fault on my Gentoo system. How can I track down the bug? By the way, what do you use for X11 monitor auto-configuration on PowerPC?
Track down the bug? strace As for PPC, I would guess Xautoconfig, but I haven't built anything for PPC recently and do not maintain any PPC packages.
OK... I've added the NLS patch to kudzu-knoppix... I'm not sure what the implications of the minimal/python USE flags are on this package. Could you explain that for me, please? I'm going to be honest with you, I don't really understand kudzu/ddcxinfo/ddcprobe/hwsetup much at all... If you think it would be best to include them all into a single package, let's say "kudzu-gentoo", then I wouldn't have a problem with it. My main concern is maintaining multi-arch compatibility, and possibly even expanding the supported architectures, especially for the ddcxinfo stuff, as I would love to have a single tool capable of doing all of the heavy lifting for X auto-detection that works on all arches (or at least most). If you're still interested in your single-package approach, file a new bug on it and we can create a new kudzu-gentoo, which we will then prefer, unless you think it would be too much of a pain.
minimal and python USE flags: - python also installs an optional Python module (haven't tested that module) - minimal is like what livecd installs, plus updfstab. This is the subset of kudzu I personnaly use. Including ddcxinfo-knoppix into future kudzu-gentoo Out of the question with the portability issue you raised. Including hwsetup into future kudzu-knoppix Hwsetup is more portable than ddcxinfo-knoppix. Also, the livecd team builds kudzu-knoppix for hwsetup only, if I am correct. Including hwsetup into the source tree would make sense and we could install only hwsetup, what we need, when livecd is in USE. The problem is that we have to maintain it as a patch.
OK... in that case, I'll add the minimal and python (now that they make sense to me... ;]) back into the ebuild. I really don't think we should add hwsetup to the ebuild if we will have to maintain the patch ourselves, unless we plan on completely building our own patched version of all of these packages, which I would prefer not to do unless absolutely necessary.
Added to CVS... thanks for all the hard work on kudzu and friends...
