- User Since
- Mar 16 2019, 9:36 AM (23 w, 1 d)
Tue, Aug 20
My testing steps:
Mon, Aug 19
- Fixes in automirror module
After sbuild -d eoan-amd:
Tue, Aug 13
See my inline comment
Sun, Aug 11
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.
Fri, Aug 9
After testing a bit, I think that pkexec does not work well with Calamares.
Wed, Aug 7
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.
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.
Sat, Aug 3
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)
Wed, Jul 31
Tue, Jul 30
Mon, Jul 29
Sun, Jul 28
I have updated the Launchpad bug report with the SRU description.
Jul 26 2019
Opened a feature request upstream. In the worst case, we can patch it ourselves, I guess.
Removed depend on light-locker
Jul 25 2019
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 <email@example.com> Thu, 25 Jul 2019 10:21:00 +0200 + lubuntu-default-settings (0.54.2) bionic; urgency=medium
Jul 23 2019
Please see also bug 1833490.
Jul 21 2019
Here it is:
Jul 20 2019
Jul 16 2019
I started with the paperwork. So far I have this:
Jul 15 2019
Jul 14 2019
I have started playing around with this and uploaded a package to https://launchpad.net/~apt-ghetto/+archive/ubuntu/ppa-test
Jul 10 2019
Jul 7 2019
@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.
Jul 6 2019
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.
Jul 4 2019
Jul 1 2019
Jun 30 2019
Jun 22 2019
Jun 12 2019
May 30 2019
May 10 2019
May 9 2019
May 6 2019
Apr 18 2019
Apr 16 2019
Apr 15 2019
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.
Apr 10 2019
I have tested this on a virtual machine (VMWare Workstation 14 Player with EFI).
Apr 8 2019
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.
Apr 4 2019
Apr 3 2019
How is it handled by ubiquity? They should have the same problem.