FS#59040 - Minor issues with Archiso

Attached to Project: Release Engineering
Opened by mrgreen (Mr Green) - Sunday, 17 June 2018, 13:41 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 23 June 2018, 22:49 GMT
Task Type General Gripe
Category ArchISO
Status Closed
Assigned To No-one
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Archiso

Namely mkarchiso

_pacman ()
{
_msg_info "Installing packages to '${work_dir}/airootfs/'..."

if [[ "${quiet}" = "y" ]]; then
pacstrap -C "${pacman_conf}" -c -d -G -M "${work_dir}/airootfs" $* &> /dev/null
else
pacstrap -C "${pacman_conf}" -c -d -G -M "${work_dir}/airootfs" $*
fi

_msg_info "Packages installed successfully!"
}

The -d does nothing!

Also getting:

[mkarchiso] INFO: Configuration settings
[mkarchiso] INFO: Command: init
[mkarchiso] INFO: Architecture: x86_64
[mkarchiso] INFO: Working directory: work/x86_64
[mkarchiso] INFO: Installation directory: arch
[mkarchiso] INFO: Pacman config file: work/pacman.conf

[mkarchiso] INFO: Installing packages to 'work/x86_64/airootfs/'...
==> Creating install root at work/x86_64/airootfs
==> Installing packages to work/x86_64/airootfs
warning: option --root is deprecated; use --sysroot instead
:: Synchronizing package databases...

Tried to track down issue possibly pacman or pacstrap (not quite sure) harmless but something to look at?

Also now that Arch is purely x86_64 is there any need for more than one package list in configs? surely efitools could go in to package list?


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Saturday, 23 June 2018, 22:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  v35
Comment by Eli Schwartz (eschwartz) - Sunday, 17 June 2018, 14:05 GMT
  • Field changed: Attached to Project (Arch Linux → Release Engineering)
  • Field changed: Task Type (Bug Report → General Gripe)
  • Field changed: Severity (Low → Very Low)
The -d flag is a deprecated no-op since https://git.archlinux.org/arch-install-scripts.git/commit/?id=0af6884aca68dcb7eed0b85fbc2960903df3d968

It could be safely removed.

The --root deprecation is not coming from archiso, it is comping from pacstrap itself and there's no way to avoid it. It's already being tracked by  FS#58778 

As for the configs, I'm not sure what the problem is. Are you suggesting to remove the empty i686 file as a followup to these commits?
https://git.archlinux.org/archiso.git/commit/?id=01b54d240624e56b3e5415b6cf56a7fc3c987f24
https://git.archlinux.org/archiso.git/commit/?id=34d6ef3fa496be9ba1ba6f4f85f81ba7b65f7e9b
https://git.archlinux.org/archiso.git/commit/?id=d5102724fbacb8f980db346e0caa8b5a85d9edb6

The packages.both vs x86_64 divide is because there could be packages that are specifically relevant to a particular architecture, and it makes archiso more flexible and extendable to support generic as well as arch-specific functionality.
Comment by mrgreen (Mr Green) - Sunday, 17 June 2018, 15:48 GMT
That said I think Arch is solely based on x86_64 so I see no reason to have i686.packages or a way of building both architectures... The loops in build script are not really needed.

Remove i686.packages and x86_64.packages files.

It is not that difficult to add in i686 or run simply with i686 as archlinux32 does.

I run a 'packages' file with packages that I add to any iso that is not part of 'base'

Yes the '-d' should be removed to reduce clutter.

# Do all stuff for each airootfs
for arch in i686; do
run_once make_basefs
run_once make_packages
done

run_once make_packages_efi

for arch in i686; do
run_once make_setup_mkinitcpio
run_once make_customize_airootfs
done

for arch in i686; do
run_once make_boot
done

This seems to make no sense to me, loops could be removed. If a user wishes to build a dual iso for any reason it is not difficult to figure that you need to run those functions twice..

Loading...