[opensuse-kubic] Re: MicroOS KDE does not mount USB drives
Hi, I reinstalled MicroOS desktop KDE this morning as the new partitioning was enabled. However as I changed my DE to KDE I could not mount my USB drive anymore. I enabled the automount removable drives in the system settings. And it still did nothing. Reboots also didn't work. As such I'm now running Gnome again and there it works as intended. I did also install nfs-client and autofs as I thought the issue might be with these packages. Do you guys know which package is missing on the KDE desktop? BR, Syds
Hi, Am Dienstag, 24. November 2020, 09:34:39 CET schrieb Syds Bearda:
Hi,
I reinstalled MicroOS desktop KDE this morning as the new partitioning was enabled. However as I changed my DE to KDE I could not mount my USB drive anymore. I enabled the automount removable drives in the system settings. And it still did nothing. Reboots also didn't work.
Does the popup appear when plugging in a drive?
As such I'm now running Gnome again and there it works as intended.
I did also install nfs-client and autofs as I thought the issue might be with these packages.
Do you guys know which package is missing on the KDE desktop?
If the popup doesn't appear, it's probably udisks2. Otherwise, logs (mostly the journal) would be useful here. Cheers, Fabian
BR, Syds _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
Thanks, I'll try udisks2 tonight as I didn't get the popup. BR, Syds On Tue, Nov 24, 2020, at 09:42, Fabian Vogt wrote:
Hi,
Am Dienstag, 24. November 2020, 09:34:39 CET schrieb Syds Bearda:
Hi,
I reinstalled MicroOS desktop KDE this morning as the new partitioning was enabled. However as I changed my DE to KDE I could not mount my USB drive anymore. I enabled the automount removable drives in the system settings. And it still did nothing. Reboots also didn't work.
Does the popup appear when plugging in a drive?
As such I'm now running Gnome again and there it works as intended.
I did also install nfs-client and autofs as I thought the issue might be with these packages.
Do you guys know which package is missing on the KDE desktop?
If the popup doesn't appear, it's probably udisks2. Otherwise, logs (mostly the journal) would be useful here.
Cheers, Fabian
BR, Syds _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
Hi everyone, On Tue, 2020-11-24 at 09:42 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 09:34:39 CET schrieb Syds Bearda:
I reinstalled MicroOS desktop KDE this morning as the new partitioning was enabled. However as I changed my DE to KDE I could not mount my USB drive anymore. I enabled the automount removable drives in the system settings. And it still did nothing. Reboots also didn't work.
As such I'm now running Gnome again and there it works as intended.
Do you guys know which package is missing on the KDE desktop?
If the popup doesn't appear, it's probably udisks2. Otherwise, logs (mostly the journal) would be useful here.
So, I think I run into the same/similar issue on GNOME, and in fact I added `udisks2` and other packages to the GNOME Desktop pattern, see: https://build.opensuse.org/request/show/840921 This (i.e., the fact that it's an issue on KDE as well) kinds of confirms something that I was wondering about already, which is the fact that some of the packages that we have under `%package desktop- gnome` would probably be useful under `%package desktop-kde`, and vice versa. Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that? Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that? Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Hi, Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Hi everyone,
On Tue, 2020-11-24 at 09:42 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 09:34:39 CET schrieb Syds Bearda:
I reinstalled MicroOS desktop KDE this morning as the new partitioning was enabled. However as I changed my DE to KDE I could not mount my USB drive anymore. I enabled the automount removable drives in the system settings. And it still did nothing. Reboots also didn't work.
As such I'm now running Gnome again and there it works as intended.
Do you guys know which package is missing on the KDE desktop?
If the popup doesn't appear, it's probably udisks2. Otherwise, logs (mostly the journal) would be useful here.
So, I think I run into the same/similar issue on GNOME, and in fact I added `udisks2` and other packages to the GNOME Desktop pattern, see:
https://build.opensuse.org/request/show/840921
This (i.e., the fact that it's an issue on KDE as well) kinds of confirms something that I was wondering about already, which is the fact that some of the packages that we have under `%package desktop- gnome` would probably be useful under `%package desktop-kde`, and vice versa.
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense. Cheers, Fabian
Regards
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too. About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern). I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in). If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern. And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful. Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns. -- 真実はいつも一つ！/ Always, there's only one truth!
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed. On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
I do have 2 other issues with MicroOS on KDE: 1) While having a second monitor connected, you can change the layout of the screens and make the second monitor the primary. However after a reboot you need to adjust the settings again. 2) The battery of my laptop is not showing the status and notifications tray only says for battery and brightness: no battery available. Which package am i missing. I checked the KDE tumbleweed pattern, but I can't see a package that would clearly be relating to battery management or power management. Also I have TLP installed already. BR, Syds On Tue, Nov 24, 2020, at 22:13, Syds Bearda wrote:
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed.
On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
On Wed, Nov 25, 2020, at 08:47, Syds Bearda wrote:
I do have 2 other issues with MicroOS on KDE:
1) While having a second monitor connected, you can change the layout of the screens and make the second monitor the primary. However after a reboot you need to adjust the settings again.
2) The battery of my laptop is not showing the status and notifications tray only says for battery and brightness: no battery available. Which package am i missing. I checked the KDE tumbleweed pattern, but I can't see a package that would clearly be relating to battery management or power management. Also I have TLP installed already.
I have tried installing powerstat and powertop, but they both don't do anything in showing the battery information..
BR, Syds
On Tue, Nov 24, 2020, at 22:13, Syds Bearda wrote:
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed.
On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
Hi, Am Mittwoch, 25. November 2020, 08:47:15 CET schrieb Syds Bearda:
I do have 2 other issues with MicroOS on KDE:
1) While having a second monitor connected, you can change the layout of the screens and make the second monitor the primary. However after a reboot you need to adjust the settings again.
Which settings exactly? Is it like everything was lost or just parts?
2) The battery of my laptop is not showing the status and notifications tray only says for battery and brightness: no battery available. Which package am i missing. I checked the KDE tumbleweed pattern, but I can't see a package that would clearly be relating to battery management or power management. Also I have TLP installed already.
Probably upower. That and udisks2 are part of https://build.opensuse.org/request/show/850666. I'll try to deduplicate that with the GNOME pattern soon (unless Dario wants to take care of that instead). Cheers, Fabian
BR, Syds
On Tue, Nov 24, 2020, at 22:13, Syds Bearda wrote:
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed.
On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli:
Now, we can put them there, of course, but that would mean quite a bit of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
Should we have some kind of `%package desktop` with common stuff, that then both the GNOME and KDE patterns depends on? Or are there better ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
hi, On Wed, Nov 25, 2020, at 09:55, Fabian Vogt wrote:
Hi,
Am Mittwoch, 25. November 2020, 08:47:15 CET schrieb Syds Bearda:
I do have 2 other issues with MicroOS on KDE:
1) While having a second monitor connected, you can change the layout of the screens and make the second monitor the primary. However after a reboot you need to adjust the settings again.
Which settings exactly? Is it like everything was lost or just parts? It doesn't save the monitor positions, and as my laptop is on the left I have to move the monitor and laptopscreen around and make the monitor the primary every reboot.
2) The battery of my laptop is not showing the status and notifications tray only says for battery and brightness: no battery available. Which package am i missing. I checked the KDE tumbleweed pattern, but I can't see a package that would clearly be relating to battery management or power management. Also I have TLP installed already.
Probably upower. That and udisks2 are part of https://build.opensuse.org/request/show/850666. I'll try to deduplicate that with the GNOME pattern soon (unless Dario wants to take care of that instead).
Yes upower fixed it. I was already looking at the Arch wiki for power management (https://wiki.archlinux.org/index.php/Power_management) but it doesn't mention upower there and powerdevil is already installed.
Cheers, Fabian
BR, Syds
On Tue, Nov 24, 2020, at 22:13, Syds Bearda wrote:
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed.
On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote:
Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli: > Now, we can put them there, of course, but that would mean quite a > bit > of duplication. How can we handle that?
Normally I'd copy whatever the non-MicroOS patterns do, for consistency. However, udisks2 is pulled in through Recommends by gvfs resp. libKF5Solid5, which don't have any effect on MicroOS due to "onlyRequires". (This is the reason why I tell users that setting onlyRequires themselves is a bad idea)
Right.
> Should we have some kind of `%package desktop` with common stuff, > that > then both the GNOME and KDE patterns depends on? Or are there > better > ways of doing that?
While I don't think the overlap is that much, a pattern for deduplication would probably still make sense.
Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
On Wed, Nov 25, 2020, at 10:02, Syds Bearda wrote:
hi,
On Wed, Nov 25, 2020, at 09:55, Fabian Vogt wrote:
Hi,
Am Mittwoch, 25. November 2020, 08:47:15 CET schrieb Syds Bearda:
I do have 2 other issues with MicroOS on KDE:
1) While having a second monitor connected, you can change the layout of the screens and make the second monitor the primary. However after a reboot you need to adjust the settings again.
Btw just did another reboot and my screensetup was saved somehow. Didn't have to change anything anymore :) Working like a charm now!
Which settings exactly? Is it like everything was lost or just parts?
It doesn't save the monitor positions, and as my laptop is on the left I have to move the monitor and laptopscreen around and make the monitor the primary every reboot.
2) The battery of my laptop is not showing the status and notifications tray only says for battery and brightness: no battery available. Which package am i missing. I checked the KDE tumbleweed pattern, but I can't see a package that would clearly be relating to battery management or power management. Also I have TLP installed already.
Probably upower. That and udisks2 are part of https://build.opensuse.org/request/show/850666. I'll try to deduplicate that with the GNOME pattern soon (unless Dario wants to take care of that instead).
Yes upower fixed it. I was already looking at the Arch wiki for power management (https://wiki.archlinux.org/index.php/Power_management) but it doesn't mention upower there and powerdevil is already installed.
Cheers, Fabian
BR, Syds
On Tue, Nov 24, 2020, at 22:13, Syds Bearda wrote:
Installing udisks2 fixed the issue with the usb drive not mounting. Thanks. No other package needed to be installed.
On Tue, Nov 24, 2020, at 14:26, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 5:50 AM Dario Faggioli <dfaggioli@suse.com> wrote:
On Tue, 2020-11-24 at 11:13 +0100, Fabian Vogt wrote: > Am Dienstag, 24. November 2020, 10:35:20 CET schrieb Dario Faggioli: > > Now, we can put them there, of course, but that would mean quite a > > bit > > of duplication. How can we handle that? > > Normally I'd copy whatever the non-MicroOS patterns do, for > consistency. > However, udisks2 is pulled in through Recommends by gvfs resp. > libKF5Solid5, > which don't have any effect on MicroOS due to "onlyRequires". (This > is the > reason why I tell users that setting onlyRequires themselves is a bad > idea) > Right.
> > Should we have some kind of `%package desktop` with common stuff, > > that > > then both the GNOME and KDE patterns depends on? Or are there > > better > > ways of doing that? > > While I don't think the overlap is that much, a pattern for > deduplication > would probably still make sense. > Ok, cool to hear you think that too.
About how big the overlap would be, well, I think it depends on how we see MicroOS Desktop (and I mean in general, for *any* DE, at least *any* DE that we support during install or with a pattern).
I mean, the GNOME pattern has CUPS and some PPD related packages, because I think that an user should be able to print (with at least some common printer models), without having to fiddle with transactional-update. It has samba, as I guess someone though (as, I don't think it was me that added me... but I may be wrong) that an user should also be able to access shares right after install. It has bluez- firmware so at least some common Bluetooth device works immediately (I see you have bluedevil5 in KDE, but I don't think it brings bluez- firmware in).
If these are things that we thing would be useful to all MicroOS Desktop users, no matter which DE they choose, then they're all candidates for being put in the common pattern.
And note that I'm not saying that, if we do the common pattern thing, we should put all those packages there immediately. I'm just thinking out loud about how it could be used / useful.
I think having a desktop-common pattern that is required by all other desktop patterns makes sense. In fact, I'm honestly surprised that we don't already do this for non-MicroOS desktop patterns.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
_______________________________________________ openSUSE Kubic mailing list -- kubic@lists.opensuse.org To unsubscribe, email kubic-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/kubic@lists.opensuse.org
participants (4)
-
Dario Faggioli -
Fabian Vogt -
Neal Gompa -
Syds Bearda