I booted the Cosmic ISO in EFI mode and didn't see it. Perhaps they only use it on the installed system, since it's GRUB that boots all the installs.
Sat, Oct 13
Fri, Oct 12
Thu, Oct 11
@tsimonq2 screwed up and forget to fix the git remotes
We've got it on the TODO list to make a video on how to do just that @The_LoudSpeaker. We'll be in touch!
Given the above, @tsimonq2 I don't think any one of us can fill out the SRU template. We need more clarity on what exactly needs to be changed.
@Climby this has officially landed but there's a wee little error preventing the installer from behaving properly. You can get around this with sudo wget -O /etc/calamares/branding/lubuntu/icon.png https://phab.lubuntu.me/file/data/moj3rnsr7vten43wzesn/PHID-FILE-gfg2n5xho5hlt7afdjnz/icon.png and then run the installer like normally.
First off, @isuzufan there is no need to learn Sphinx. It's just a build tool. All you need to learn is git and Arcanist as I linked above. I'd be happy to walk you through that. Do you do IRC or what's a good way to connect for real time chat if need be?
On the other hand $XDG_CURRENT_DESKTOP is LXQt. I'm not sure why they're looking to $DESKTOP_SESSION instead.
Wed, Oct 10
@isuzufan first off, good to have you here and thanks for the offer of help! The manual is held in a repository (rMANUAL) which is essentially composed of a bunch of text files in a reStructuredText format. Like other lightweight markup languages, it's highly readable except for some directives for building, which you can ignore. Every hour the public facing manual is rebuilt using the current code base. If you're familiar with using git, you can just submit pull requests using the cool little Phabricator tool Arcanist. If you need further explanation, don't hesitate to ask!
BTW built fine, so should be good.
- applied them to both getcountry() and getmirror()
- made PEP8 happy with them
To be clear, the problem is that the patch would work, but the upstream code doesn't allow LXQt as a valid value for desktopEnvironment. The appropriate places to fix are denoted by oSoMoN.
Merge proposal in place.
Yeah well I just got that far, too, and it's all sorts of screwed up. I'm just going to go ahead and submit it. BTW, I put your name on it.
Nothing. Building as we speak.
Nevermind. Looking at the example you gave that GNOME used, I think it's clear it's sufficient because the rest of the patch is a test.
@hmollercl are you sure that's sufficient?
Tue, Oct 9
Get upstream to make something.
Revised the thing again.
Yes, it should not be -signed on ia32. My bad.
Revised slightly. Try again.
Mon, Oct 8
Add a --- as the first line.
2018-10-08 - 20:57:26 : ERROR: YAML parser error yaml-cpp: error at line 2, column 10: illegal map value
FYI this is now on the images and it did work correctly.. but I don't have a weird system to test it on. However, since it's a wildcard, if it works for anything, it should work for everything.
Look in $HOME/.cache/Calamares/session.log for an error that might point us in the right direction.
It's in there and tested and looks good!
He probably hates it, but we should to some degree consider this almost a brand new flavor release.
Well we can't do less, so yes. :)
I know it sounds a little weird, but you know as well as I do this release is not as complete as previous ones.
More to come but immediate thought: let's get some cool multiscreen screen shots!
Minimal support cycle then. It'll save us extra effort.
Updated the earlier comment.
Does upstream have no intention of doing it themselves?
@tsimonq2 you're missing some characters. also, there's no difference between those two.
I guess what I'm saying is we should consider their schedule. If it's not going to be until after 9 months, who cares. If they're thinking 3 months, we should minimize our support cycle as much as possible.
My concern is that adding any logic within the efi section will actually produce the results we want. In that other issue we had, it seemed to match a 'firmwareType' other than bios or efi. Also, I didn't mean uname, duh. So actually I might propose a mix of the two ideas:
My general feeling is that at least early in the cycle, we'll be fixing bugs on both. Later, we're likely to see upstream fixes and then it's kind of going to be a pain. Maybe we should base this on the likely release date of the next LXQt. Can we get that out of them?
Sun, Oct 7
Dude every time I say "already tested" or "known to work" you seem to not pay attention to it.