Yep

Alright, I'm writing this all down in one place so I don't forget and others can rubber ducky me. Basically, we need to set Calamares up to configure some custom settings, iff the OEM GRUB entry is set. This isn't horribly complicated at all.

:P

This task remains here so that it does get added there.

Exactly. Move everything over, it doesn't belong here. :P

Spite closes things, dummy.

Put it in rNEWREL New Release Tooling :P

The sloppy way we dealt with release notes and the website indicates how important things like this are.

It better be done. Cuz it's out.

I prefer to pass on this, not much time and I don't have problematic machines anymore to test. However, apparently there is a better solution for broadcom than it was before when I had the issue packaged in bcmwl-kernel-source.
Could we seed it?
https://packages.ubuntu.com/disco/bcmwl-kernel-source

@hmollercl you're probably right, but I've seen cases where live works but the install doesn't. In any case, I want to know what Ubuntu proper does so we can emulate that. You have any interest in digging into that quagmire?

Why in https://phab.lubuntu.me/w/lubuntu-dev/new-code/ this appear to be C++? It could be done in Python to.

Single Sign On

What's SSO?

I understand the issue with wireless drivers (Broadcom comes into mind) but graphic cards?
I mean if there are graphic chards drivers necessarily needed (ie nouveau doesn't work) calamares wouldn't start, am I wrong?
Besides Broadcom, any other drivers you are aware of?

regarding galternatives...
https://forum.lxqt.org/t/lxqt-config-on-debian-recommends-galternatives/698/2

Looks like the golang stuff is gone. The others would be nice to remove, but we took care of the big stuff.

I would suggest we just add this to rNEWREL New Release Tooling, sort of like how the Ubuntu release checklist is.

so, now we are about to discuss to ship those input methods
it is very happy news
Thank you for ^^

T63: Add support for Differential Revisions in Lugito

@wxl could you please make a separate task?

Just to make it easily accessible here's the line in the branding.desc that deals with window behavior.

You hit the nail on the head @wxl :)

Differential revisions, too.

And VirtualBox 6 I might add. That might also have something to do with it.

Well here's a weird thing: I haven't had any problem with 19.04 in VirtualBox booting to a reasonable size, i.e. not a little 800x600 screen. Whether or not that's true, I don't think we need to make it so urgent, especially when the release notes link to a bug that provides a simple workaround: go full screen.

Well, regardless of whether or not it's going to be subiquity (the "s" supposedly stands for server), there is supposedly a new installer in the works.

Hooooooooooooooooooooooooooooooooold up. Doesn't "check disc for defects" ultimately accomplish the same purpose, except that the user is not forced to run it? Couldn't we build that into the GRUB entry for loading the image, i.e. it would first check for defects and then boot the image?

and would function the same as selecting the boot entry (on BIOS I think?)

@tsimonq2 I think you've still ignored some of the question asked:

@tsimonq2 I'm not sure we have the mechanism to create an interruptible SystemD unit like that. Will have to look into it.

I said on the devel channel yesterday(?) that I think it's too late for release, but seeing as it's default in Virtualbox, it makes it much more urgent in my eyes. If we want to retest everything, Adam did say this on Thursday...

[20:53] <infinity> tsimonq2: Ultimately, for packages only you seed, you have final say anyway (up to a point).  If you want to upload something and respin and retest all your crap 6 hours before release, be my guest.
[20:53] <infinity> tsimonq2: If you want to do it an hour before release, you might have missed your window. :P

That being said, I want @guiverc's input on this, because he's the AWESOME (seriously!) tester who has been plowing through the testcases.

Packageset updates are manual, and I poked cyphermox at one point. I'll poke him again, at which point we can close this task, I think.

The new "Next Generation" installer subiquity is supposed to replace ubiquity

Also, @teward has more experience with this, but once we get something working, we need a systemd unit (again, probably mirrored after Fedora's) and some packaging (which I can handle).

I'd like it to function very similar to Fedora's, where, on boot, it goes through something like "Verifying checksums... 0% (Press Esc to cancel)"

Please add requirements:

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

Just created a bug regarding an 800x600 screen (default in VirtualBox). Fullscreen would fix this regardless of the solution upstream comes up with. I will note they don't like scroll bars so the code currently enlarges the window and adds a scroll bar only if necessary. Ew.

For the easy win we could set windowExpanding: fullscreen in the branding.desc file to force calamares into full screen mode.

…but the golang stuff is still in our packageset. @tsimonq2 ?

I can confirm ubuntu-report is not in the platform seeds, at least in that I ran grep -R ubuntu-report * in the repo with no results.

Did we get it in too late for the ISO to build with it? (Also a side question: are seeds germinated as part of the ISO creation process or does that have its own cron job?).

@tsimonq2 I see that you accepted {D7} for disco. As of 20190413.1, ubuntu-report is still in there. Did we get it in too late for the ISO to build with it? (Also a side question: are seeds germinated as part of the ISO creation process or does that have its own cron job?).

I tried setting the global $BROWSER to to a null value and then changing the default and the file associations didn't get updated. Long story short just using the variable at all is problematic. I can't see of a good way to fix it until upstream switches mechanisms. ☹

The GNOME ones are the UI components for Network Manager. The base ones are the API-level plugins (though they work with nmcli).

Jinx ;)

My guess is that the GNOME ones are the UI components and the regular packages are the APIs and such. Can someone confirm that?