Hi, Petter Reinholdtsen <p...@hungry.com> wrote (Sun, 07 Mar 2021 08:13:31 +0100): > 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?
I fear, all the above is out of my skills. And for the (graphics) firmware problem, isenkram is of no help as it seems, at least for Bullseye. Holger -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076