drakx/perl-install/common.pm, branch 18.73 Mageia Installer and base platform for many utilities Use POSIX::setlocale() instead of c::setlocale(). 2025-11-02T18:20:25+00:00 Martin Whitaker mageia@martin-whitaker.me.uk 2025-11-02T12:50:05+00:00 b518f9f16b0fc09802d238eef91de41ed54de282 Since Perl 5.28, Perl has used the thread-safe uselocale() functions from the C standard library when setting the locale. Once a thread-safe locale setting has been made, the Locale::gettext functions will use those settings, not the global locale settings. So calling the drakx c::setlocale() and c::init_setlocale() functions, which still use the underlying setlocale() function from the C standard library normally has no effect. However, prior to Perl 5.38, there was a bug in Perl that could cause the main thread to revert to using the global locale settings, and it it would seem this bug was being triggered by the stage2 installer, meaning it still properly translated the UI after the language selection step. Now we have a newer version of Perl, this is no longer so, and the UI contiues to be in English after the user has selected a different language (mga#34656). The POSIX::setlocale() function affects the thread-safe locale, so can be used to fix this bug. This patch removes the c::setlocale() function to prevent reintroduction of this bug, and moves the c::init_locale() function to the common module. 
Since Perl 5.28, Perl has used the thread-safe uselocale() functions
from the C standard library when setting the locale. Once a thread-safe
locale setting has been made, the Locale::gettext functions will use
those settings, not the global locale settings. So calling the drakx
c::setlocale() and c::init_setlocale() functions, which still use the
underlying setlocale() function from the C standard library normally
has no effect. However, prior to Perl 5.38, there was a bug in Perl
that could cause the main thread to revert to using the global locale
settings, and it it would seem this bug was being triggered by the
stage2 installer, meaning it still properly translated the UI after
the language selection step. Now we have a newer version of Perl, this
is no longer so, and the UI contiues to be in English after the user
has selected a different language (mga#34656).

The POSIX::setlocale() function affects the thread-safe locale, so can
be used to fix this bug.

This patch removes the c::setlocale() function to prevent reintroduction
of this bug, and moves the c::init_locale() function to the common module.
Ensure efivarfs is mounted in the chroot when running the installer. 2022-10-25T17:46:55+00:00 Martin Whitaker mageia@martin-whitaker.me.uk 2022-10-25T17:46:55+00:00 1d1d49e4f422e6e5ef8204b6cdcca8fd8cdf5f14 If the efivarfs was already mounted in the installer runtime environment, the previous code would detect that and not mount it in the installed system enviroment. Currently this doesn't happen unless the user manually mounts it, but protect against that and against future changes. 
If the efivarfs was already mounted in the installer runtime environment,
the previous code would detect that and not mount it in the installed
system enviroment. Currently this doesn't happen unless the user manually
mounts it, but protect against that and against future changes.
Factor out code to mount the efivarfs pseudo-filesystem. 2022-10-24T20:07:25+00:00 Martin Whitaker mageia@martin-whitaker.me.uk 2022-10-24T20:07:25+00:00 325cbdb1eeff9310c305bfb4c29bf7f03556655f 






perl_checker cleanups + kill unused variable
2020-03-25T07:05:39+00:00

Thierry Vignaud
thierry.vignaud@gmail.com

2020-03-24T09:47:46+00:00

55bc7ba0df2271059a114c6621c429ff96c44149












drakboot: support setting up uefi on aarch64
2020-01-01T14:43:45+00:00

Pascal Terjan
pterjan@mageia.org

2019-12-31T19:25:40+00:00

b20813c771ce7abd72d7c42338f7b1a6b245ff8a

Partially tested on Amazon EC2, instance still didn't boot (as it
needed it to be installed in removable mode (EFI/boot/bootaa64.efi)
to be found) but at least drakboot --boot worked (except for
failing to enabled acpid service) and things seem to be in the
expected place.





Partially tested on Amazon EC2, instance still didn't boot (as it
needed it to be installed in removable mode (EFI/boot/bootaa64.efi)
to be found) but at least drakboot --boot worked (except for
failing to enabled acpid service) and things seem to be in the
expected place.







Add extra UEFI helper functions.
2018-12-17T18:16:24+00:00

Martin Whitaker
mageia@martin-whitaker.me.uk

2018-12-16T22:25:44+00:00

51f5733e7910fdf7c99ef9da67fbb5d0d7ef51c1

Needed for next commit.





Needed for next commit.







fix doble quotes in perldoc
2018-01-07T20:22:09+00:00

Thierry Vignaud
thierry.vignaud@gmail.com

2017-10-09T12:03:18+00:00

f107fdf1e388ba0f58b4f11939f56b5e0f4f68fa












kill now useless is_mgalive()
2017-04-04T18:06:18+00:00

Thierry Vignaud
thierry.vignaud@gmail.com

2017-04-03T15:21:08+00:00

121369c77f8121376546b6094851fb1036665ed0












rely on Gtk+ for checking for Xserver (mga#19498)
2017-01-12T15:40:09+00:00

Thierry Vignaud
thierry.vignaud@gmail.com

2017-01-12T15:38:15+00:00

912abc9725196eded7554813e4d6adb91e66f169

MCC also needs a separate fix for forcing using the X11 GDK backend b/c
GtkPlug/Socket do not work under Wayland, thus relying on xwayland

XFdrake will probably fails the same way under wayland, but anyway it's
there for configuring xserver...
It should probably checks for wayland before proposing to test





MCC also needs a separate fix for forcing using the X11 GDK backend b/c
GtkPlug/Socket do not work under Wayland, thus relying on xwayland

XFdrake will probably fails the same way under wayland, but anyway it's
there for configuring xserver...
It should probably checks for wayland before proposing to test







(get_libdir) introduce it
2016-06-24T15:49:49+00:00

Thierry Vignaud
thierry.vignaud@gmail.com

2016-06-24T15:38:46+00:00

b8ac3a77825a5d742f445f217a6688532f3d0345

it'll be reused in compssUsers.pl





it'll be reused in compssUsers.pl