mdadm no arrays found in config file...

[towo]

Try to change libavcodec61 to libavcodec62 in base-media.

[ro_sid]

@towo: Thanks for that information. It seems worthy. But guess what, now it's the 'policycoreutils-dbus', which we discussed in another thread. (The dependency missing is 'policycoreutils-python-utils' (in the required version). One Siduction-Member (@Teriarch iirc) provided a (mock) package that is a recompilation of the 'old' package with the required version number. That works well for me. We shortly discussed, if that package could go in a repo (e.g. 'fixed'), but there is the worry, that this package will not be overwritten by a Debian-provided one - the official package.)

For testing purposes I have now explicitly ('-' at the end) deselected 'policycoreutils-dbus' in 'base-security'. Now the ISO is generated, but I cannot tell, what consequences come of the modification. [And I cannot test that today.]

[towo]

Remove policycoreutils-dbus it's not really needed.

[Teriarch]

Try this one first:
<https://wormhole.app/Q5L3p1#8BpMI2pEh8fFcbHSYLhZqw>
It contains an additional line:
Provides: policycoreutils-python-utils (= 3.10.1)
Don't know if that solves the dependency problem.

PS.:
No it doesn't. Problem is the wrong policycoreutils-python-utils (version 3.10-1) package being fetched from the
server during the build. Is there a possibility to include one's own packages during the build? Once the ISO is built,
the wind of change is gone. 

[Teriarch]

@ro_sid
Here is something else you can do in case you want to install any packages
you are still missing. Modify line 79 of file
.../pyfll/pyfll/packages/packages.d/finalize.postinst
like so:

Code Select Expand

  LIVE_SETTINGS='none'
  if [ -f /usr/bin/livesettings ]; then[/font]
      say "Configure Live Settings ... (current livesettings scripts)"[/font]
      livesettings configure[/font]
      LIVE_SETTINGS='found'[/font]
  fi
  /bin/sh  # line 79
  if [ "$LIVE_SETTINGS" = 'none' ]; then
      echo 'No live settings scripts found! Please fix! (exit in finalize.postinst)'
      exit 1
  fi
This way you delay execution by dropping out into a root shell within the chroot environment.
Now you can do whatever you want (install other packages, set root pw, modify the system, etc).
All your changes will be reflected in the squashfs and final ISO image. You started ./fll with a
-o /tmp/fll option, so the chroot can be seen and handled as /tmp/fll/fll_<random>/amd64 from
outside. You could easily drop in our modified policycoreutils-python-utils_3.11-1_all.deb from
an outside shell into /tmp/fll/fll_b44p8i5w/amd64/tmp. The file would be seen as
/tmp/policycoreutils-python-utils_3.11-1_all.deb from the drop out shell inside the chroot
environment and can be installed using "dpkg -i". Since we dropped out into finalize.postinst
everything else is already said and done. If you leave the chroot environment with ctrl-d the
python script pyfll resumes and finalizes the creation of the ISO image.

HTH

[ro_sid]

@Teriarch: Thanks for the valuable tip. I am sure I can use that information to my advantage. Even later.
At this time I have disabled the policycoreutils-dbus package. But to solve my 'loop0'-problem, I plan to make a systemd (additional) package to just revive the rc.local execution. If I succeed, it could go along with the intermediate policycoreutils-python-utils package. Finally the manual intervention step should be made unnecessary.
At this moment, to build a (KDE-)Siduction-ISO-image, I also have to disable a 'qcom'-firmware package. It's a very 'dynamic' stage  now. Too much for my liking. I wish, the developers would fix dependent packages faster. E.g. to install virtualbox again without any tricks.

I'm quite sure what would help a lot is a "package unavailable" script listing it at least for dependent packages. Better even to list them all, together with the "urgency" they are wanted (depends, recommends, suggests etc.), and possibly by which package. I can see those in interactive aptitude, but I didn't succeed to get it from another program capable of being scripted.
Thanks again.