Hi Holger,
[Holger Wansing] > OK, so there might still be some hope :-) Perhaps. :) I unsuccessfuly tried to be breafer. There seem to be two issues here. One seem to be a bug or misfeature either in isenkram or appstream, leading to long run times. The other is lack of appstream mapping information for the firmware-amd-graphics package, one I do not know much about. I do not know the solution to the former, and currently lack the time to dive into it. Did a quick look at the code, though, see below. As for the latter, the easiest way I know to check the current appstream content is to run appstream2modaliases from the isenkram source, and look for firmware-amd-graphics. It is not mentioned in the output, nor in the modaliases file included in isenkram, so there is no knowledge available for isenkram about what kind of hardware that package would be useful for. The generic solution is to get the firmware-amd-graphics maintainer to add appstream metadata mapping to the PCI IDs supported by the package, <URL: http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html > and <URL: https://wiki.debian.org/AppStream/Guidelines > provide some clues on how to do this. If the maintainer is unwilling or while we wait for an updated package there is a short term solution. We can add the same mapping to the modaliases file provided by isenkram, and upload isenkram instead. As you can imagine, without hardware-package mapping information, isenkram can not do much, and in this case the mapping is missing. I suspect Debian will need to use such mapping in the default installation for a few releases before most relevant developers become aware of the need and give priority to adding it to their packages. Luckily there are not that many maintainers with hardware specific packages, so it is not an enormous job to convince them. Unfortunately I have lacked the capacity the last few years to attack the issue myself, and this is likely to continue, so someone else will have to convince them. I did submit quite a few BTS requests over the years for the mappings I am aware of (see the /usr/share/isenkram/modaliases in isenkram-cli for those I am aware of), but ran out of steam and time. Perhaps it is also possible to merge the modalias information in kernel modules with their requested frimware files and the packages that provide them, to extract these mappins automatically from the archive? I suspect so, but have not tried so myself. In any case, the information must show up in appstream (or isenkram) to be useful. > Next, I executed 'isenkram-pkginstall'. A long list of > binary/firmware files came up, with the informal line "info: locating > packages with the requested firmware files" Then, the machine seemed > to hang for about 25 minutes! top showed, that there were many > appstreamcli processes running (like 'appstreamcli what-provides > firmware:runtime radeon/CAYMAN_me.bin'). It sound a bit like this code in isenkram-autoinstall-firmware might take a long lime, specificly the appstreamlookup call: loginfo "locating packages with the requested firmware files" binpkginfos="" binpkgs="" for fwfile in $fwfiles ; do # First check appstream, next look in our local files if they exist binpkginfo=$(appstreamlookup $fwfile) if [ "$binpkginfo" ] && [ "$datafiles" ]; then fwfilere=$(echo $fwfile | sed -e 's%/%\\/%g' -e 's/\./\\./g') binpkginfo="$(awk "/^lib\/firmware\/$fwfilere/ {print \$2}" $datafiles)" fi if [ -z "$binpkginfo" ] ; then # Special case for b43 where the firmware is # undistributable by Debian. case "$fwfile" in b43/*) add_contrib_nonfree binpkgs="${binpkgs:+$binpkgs }firmware-b43-installer" ;; esac else binpkginfos="$binpkginfos $binpkginfo" fi done > Then I called tasksel and selected the new entries generated by > isenkram (Hardware specific packages (autodetected by isenkram and > Hardware specific firmware packages (autodetected by isenkram). That > lead to the same hanging machine again, as above, again for ~25 > minutes. If my suggestion is right, the delay is because of the second tasksel option, not the first. I have no idea how to make the appstream lookup quicker in shell script. Perhaps it need to be rewritten to python to avoid loading the appstream database on every lookup? -- Happy hacking Petter Reinholdtsen
