My testing steps:

• Fixes in automirror module

After sbuild -d eoan-amd:

See my inline comment

The default, and therefore expected, behaviour is, that the Grub menu is only shown with several installed operating systems. It would make some users angry, if they would see the Grub menu and wait 3, 5, 10 seconds until it boots. Why should there be a Grub menu, if you only have one operating system?

Opened upstream issue.

After testing a bit, I think that pkexec does not work well with Calamares.

I have no problem to make recommendations like 1 or even 2 GiB of RAM. And we can or should write these recommendations and the minimum requirements into the manual/blog/download page/forum, so that it will be hard not to find them.

In T72#1808, @hmollercl wrote:

So, less than 1Gb RAM shouldn't be an option.

I disagree. The point of minimum requirements is, that we prevent users from installing, if the machine does not fulfil the minimum requirements (e.g. on hardware with 256 MiB). The minimum requirements should be based on technical facts and not impose unnecessary limits.

The reason, why the stable lxqt-archiver build is failing is always the same:

+ uscan --download-current-version
uscan warn: In debian/watch no matching hrefs for version 0.0.96 in watch line
  https://github.com/lxqt/lxqt-archiver/releases .*/lxqt-archiver-([\d\.]+).tar.xz
Build step 'Execute shell' marked build as failure

On https://github.com/lxqt/lxqt-archiver/releases there is no lxqt-archiver-0.0.96.tar.xz to download.

Without any log files or stack traces, it is quite challenging to find out the reason. (Maybe you have to clean the logfile from access tokens and other sensitive data prior to publish them)

@guiverc On our Download page, we have also magnet links. I hope it is not blocked by your government.

I have updated the Launchpad bug report with the SRU description.

Opened a feature request upstream. In the worst case, we can patch it ourselves, I guess.

Removed depend on light-locker

Newest debdiff:

diff -Nru lubuntu-default-settings-0.54.2/debian/changelog lubuntu-default-settings-0.54.3/debian/changelog
--- lubuntu-default-settings-0.54.2/debian/changelog	2019-02-04 06:56:24.000000000 +0100
+++ lubuntu-default-settings-0.54.3/debian/changelog	2019-07-25 10:21:00.000000000 +0200
@@ -1,3 +1,11 @@
+lubuntu-default-settings (0.54.3) bionic; urgency=medium
+
+  * Set the default lock to light-locker-command instead of lxlock
+    (LP: #1812594)
+  * Add light-locker as dependency
+
+ -- apt-ghetto <apt-ghetto@lubuntu.me>  Thu, 25 Jul 2019 10:21:00 +0200
+
 lubuntu-default-settings (0.54.2) bionic; urgency=medium

Please see also bug 1833490.

In T90#1459, @wxl wrote:

Can you share the debdiff for the change just to be perfectly clear?

Here it is:

After testing:

I started with the paperwork. So far I have this:

I have started playing around with this and uploaded a package to https://launchpad.net/~apt-ghetto/+archive/ubuntu/ppa-test

@guiverc Update /etc/default/grub

#GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_DISTRIBUTOR='Lubuntu'

and sudo update-grub.

Writing something new is maybe easier, because hardinfo is based on C.

There is also the russian group: https://t.me/Lubuntu_Ru

The efibootloaderId from https://phab.lubuntu.me/source/calamares-settings-ubuntu/browse/master/lubuntu/modules/bootloader.conf$33 is something else and is used only when installed in the UEFI mode.
This value is taken for the name of the bootloader entry in the NVRAM (where UEFI is looking for the bootloader to choose) and the name of the folder on the EFI-System-Partition (ESP). Most users don't see these entries very often, because they don't change the UEFI boot order settings often and don't search in the folders on the ESP.
I don't know, if Secure Boot takes into account the path on the ESP. I don't think so.
Changing the efibootloaderId to lubuntu could create another "problem", especially when other *buntus are installed. If there are updates for Grub, it will execute a grub-install. I don't know, where the value for the option --bootloader-id comes from during the installation of the new Grub package. Maybe we have then an older Grub in $ESP\EFI\lubuntu and a newer Grub in $ESP\EFI\ubuntu and for each bootloader two entries in the NVRAM (shimx64.efi and grubx64.efi).
The other flavours use, as far as I know, ubuntu and I think it is a good idea to have a common base, so I don't recommend to change the efibootloaderId.

In T30#1253, @The_LoudSpeaker wrote:

Hmmm. 🤔 I don't know why grub is creating the entry named "Ubuntu" for you when you have lubuntu installed.

Please add requirements:

• Use case?
• Which hashes?
• What should be checked?

I made a Pull Request on Github to fill the content of the release notes a bit. A lot of the content I have copy&pasted from the previous release notes and adjusted some numbers.

I have tested this on a virtual machine (VMWare Workstation 14 Player with EFI).

In T2#416, @tsimonq2 wrote:

My understanding from talking to cyphermox is that we have all of the GRUB modules in order.

I am not sure, if this is true. As far as I understand it, the Grub modules are under /boot/grub, which is in the encrypted LUKS container. The Grub bootloader is on the EFI-System-Partition and should unlock the LUKS container to load the kernel, but cannot do it, because it does not have all the necessary modules.

In T36#356, @kc2bez wrote:

In T36#354, @apt-ghetto wrote:

How is it handled by ubiquity? They should have the same problem.

Ubiquity uses a separate /boot partition that is unencrypted.

How is it handled by ubiquity? They should have the same problem.