On Tue, Apr 6, 2021, at 08:48, Axel Braun wrote:

Am Montag, 5. April 2021, 22:10:08 CEST schrieb Larry Finger:

...

Could anyone tell me who is in charge of handling the initial configuration of Leap 15.3. As reported in bsc#1183125, an installation of Leap 15.3 in a VirtualBox VM does not install virtualbox-guest-x11 or virtualbox-guest-tools, and only suggests virtualbox-kmp-default. This behavior differs from that of previous versions which detected that the installation was under VirtualBox and installed these 3 additional packages.

In that context (initial config) I have a question as well: We are shipping Firefox as default browser and an openSUSE homepage.

Why does this/our homepage show google as primary search engine? AFAIK is Mozilla Foundation being paid for shipping google as primary search engine. But are we? Do we have to show google as primary search engine? How about DuckDuckGo?

I myself am a user of qwant.com instead of Google. But I wouldn't mind changing it to DuckDuckGo, as long as it's not Google. If someone really wants to use Google, they can always change it back. /Syds

Cheers Axel

Am Dienstag, 6. April 2021, 08:53:02 CEST schrieb Sasi Olin:

On Di, Apr 6, 2021 at 08:48, Axel Braun wrote:

...

Why does this/our homepage show google as primary search engine? AFAIK is Mozilla Foundation being paid for shipping google as primary search engine. But are we? Do we have to show google as primary search engine? How about DuckDuckGo?

Everybody suggests something else so if you wanna discuss it I invite you to do so in the existing PR that was left stagnant: https://github.com/openSUSE/search-o-o/pull/10

As this one was declined.....

Alternatively create your own if you disagree with their choice, but then again, I'm not sure we are gonna reach a conclusion that satisfies everybody, so we are using the most popular choice instead ;)

...I opened a new pull request to set the default search engine to DuckDuckGo: https://github.com/openSUSE/search-o-o/pull/15 So far one week w/o any reaction.... Cheers Axel

On Wed, Apr 07, 2021 at 03:00:24PM +0930, Simon Lees wrote:

On 4/6/21 5:40 AM, Larry Finger wrote:

...

Could anyone tell me who is in charge of handling the initial configuration of Leap 15.3. As reported in bsc#1183125, an installation of Leap 15.3 in a VirtualBox VM does not install virtualbox-guest-x11 or virtualbox-guest-tools, and only suggests virtualbox-kmp-default. This behavior differs from that of previous versions which detected that the installation was under VirtualBox and installed these 3 additional packages.

This really should be done at a package level or possibly at pattern level (but probably not in this case). Because if someone does "zypper in virtualbox" post install ideally it should behave in the same manor so I suspect the best solution is for the virtualbox package to recommend these so that all users get the same consistent experience.

This is about installation in guest. So the guest should detect the hardware and install the appropriate driver. I think only the installer has any logic to do that, once installed it is up to the user to install the drivers for any new hardware. Thanks Michal

On 07/04/2021 12.09, josef Reidinger wrote:

On Wed, 7 Apr 2021 09:40:19 +0200 Michal Suchánek wrote:

...

On Wed, Apr 07, 2021 at 03:00:24PM +0930, Simon Lees wrote:

...

On 4/6/21 5:40 AM, Larry Finger wrote:

...

Could anyone tell me who is in charge of handling the initial configuration of Leap 15.3. As reported in bsc#1183125, an installation of Leap 15.3 in a VirtualBox VM does not install virtualbox-guest-x11 or virtualbox-guest-tools, and only suggests virtualbox-kmp-default. This behavior differs from that of previous versions which detected that the installation was under VirtualBox and installed these 3 additional packages.

This really should be done at a package level or possibly at pattern level (but probably not in this case). Because if someone does "zypper in virtualbox" post install ideally it should behave in the same manor so I suspect the best solution is for the virtualbox package to recommend these so that all users get the same consistent experience.

This is about installation in guest. So the guest should detect the hardware and install the appropriate driver.

I think only the installer has any logic to do that, once installed it is up to the user to install the drivers for any new hardware.

In fact it is not true. rpm or libzypp ( not sure which one ) has capability to do supplements based on hardware.

See e.g. nouveau spec Supplements part https://build.opensuse.org/package/view_file/X11:XOrg/xf86-video-nouveau/xf8...

Having it in installer is possible, but it take more time and effort to keep it maintained. So having it in rpm spec file is preferred way as it works even for upgrades if you have allowed recommended packages.

And how do you handle installing the correct guest packages for vmware, virtualbox, or any other, depending on the actual hardware detected? Because this was working in the past, somehow. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Wed, 07 Apr 2021 12:47:35 +0200, Ancor Gonzalez Sosa wrote:

On 4/7/21 12:13 PM, Carlos E. R. wrote:

...

On 07/04/2021 12.09, josef Reidinger wrote:

...

On Wed, 7 Apr 2021 09:40:19 +0200 Michal Suchánek wrote:

...

On Wed, Apr 07, 2021 at 03:00:24PM +0930, Simon Lees wrote:

...

[...]

This really should be done at a package level or possibly at pattern level (but probably not in this case). Because if someone does "zypper in virtualbox" post install ideally it should behave in the same manor so I suspect the best solution is for the virtualbox package to recommend these so that all users get the same consistent experience.

This is about installation in guest. So the guest should detect the hardware and install the appropriate driver.

I think only the installer has any logic to do that, once installed it is up to the user to install the drivers for any new hardware.

In fact it is not true. rpm or libzypp ( not sure which one ) has capability to do supplements based on hardware.

See e.g. nouveau spec Supplements part https://build.opensuse.org/package/view_file/X11:XOrg/xf86-video-nouveau/xf8...

Having it in installer is possible, but it take more time and effort to keep it maintained. So having it in rpm spec file is preferred way as it works even for upgrades if you have allowed recommended packages.

And how do you handle installing the correct guest packages for vmware, virtualbox, or any other, depending on the actual hardware detected?

Because this was working in the past, somehow.

It has always worked by the same mechanism described by Josef - modalias dependencies at package level. For example, the virtualbox-guest-tools package includes this line.

Supplements: modalias(pci:v000080EEd0000BEEFsv*sd*bc*sc*i*)

Right, and the installation of such packages could be done via zypper inr --no-recommends (I find it a bit confusing to use inr with --no-recommends, but it's a different story :) I guess Michal's point is about *who* triggers this detect-and-install step on the already installed system. AFAIK, user still has to trigger the above manually. Takashi

On 4/7/21 6:06 AM, Carlos E. R. wrote:

...

It has always worked by the same mechanism described by Josef - modalias dependencies at package level. For example, the virtualbox-guest-tools package includes this line.

Supplements: modalias(pci:v000080EEd0000BEEFsv*sd*bc*sc*i*)

Ok, but what decides to automatically install virtualbox-guest-tools or any other?

How can one generate/verify that modalias? I thought that it used to work, but now I am not sure. I created a new VM and installed Leap 15.1 on it. The kernel modules were installed, but not the necessary guest packages. Larry

On 4/8/21 9:20 PM, Lubos Kocman wrote:

I think you want to open a bug against patterns in general, that would be then openSUSE Release team. Otherwise Yast also handles some of hardware related detection and installation of related software (nvme etc...).

I think i'm still the bugowner for many of the patterns that aren't the general responsibility of some other team (Gnome ones for example) dating back to when I did the split a few years back. I haven't checked the list of which ones recently but I do get the occasional bug report. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B